# Kubermatic — Full Content > Easily manage multiple Kubernetes clusters with the automation power of the Kubermatic platform. Scale your business with reliability. > Last updated: 2026-07-10 > Pages: 548 --- ## What a SPARK Leader Recognition Reveals About Edge Kubernetes - **URL:** https://www.kubermatic.com/blog/what-a-spark-leader-recognition-reveals-about-the-future-of-edge-kubernetes/ - **Date:** 2026-07-07 - **Description:** QKS Group named Kubermatic a SPARK Leader in Edge Kubernetes Platforms. Explore the trends shaping sovereignty, AI, resilience, and distributed infrastructure. - **Categories:** Company - **Tags:** Announcements - **Authors:** Abubakar Siddiq Ango Recently, QKS Group recognized Kubermatic as a SPARK Leader in the SPARK Matrix™: Edge Kubernetes Platforms, Q3 2026. The evaluation assessed 10 vendors in the Edge Kubernetes Platform market and positioned Kubermatic among the top five SPARK Leaders globally, based on Technology Excellence and Customer Impact. When we read the analyst's assessment, we saw many of the same challenges our customers have been discussing with us: operating Kubernetes in disconnected environments, maintaining infrastructure independence, supporting sovereign cloud initiatives, and preparing platforms for the next wave of AI workloads. Those are precisely the problems we've chosen to focus on. ## Sovereignty Is Becoming a Platform Requirement One of the themes highlighted by QKS Group is Kubermatic's support for sovereign and distributed cloud environments. This is a trend we've been watching closely. Across Europe and beyond, organizations are re-evaluating where workloads run, who controls infrastructure, and how dependencies on individual cloud providers affect long-term flexibility. For us, sovereignty and resilience have been key focus areas for years. As Sebastian Scheele, CEO and Co-Founder of Kubermatic, puts it: > ***"Being recognized as a Leader is a strong validation of our vision for open, scalable, and sovereign infrastructure. We believe organizations should be able to build cloud-native platforms that remain secure, resilient, and under their control."*** We believe organizations should be able to run Kubernetes wherever it makes sense for their business, while maintaining control over their infrastructure, data, and long-term technology choices. ## The Reality of Disconnected Operations Many edge environments cannot assume permanent connectivity. Organizations need to operate applications across factories, retail locations, defense environments, critical infrastructure, healthcare facilities, and remote sites. These environments often have intermittent connectivity, strict regulatory requirements, and increasingly, AI workloads that cannot depend on a round trip to a central cloud. This is why we've invested heavily in autonomous operations and Kubernetes lifecycle management that continues to function even when connectivity to a central control plane is unavailable. Workloads should continue running regardless of network conditions. This has become increasingly important as organizations push more business-critical applications to the edge. ## AI Is Moving Closer to the Source Another area highlighted in the SPARK Matrix™ is our early investment in AI-native operations. While much of the AI conversation focuses on large centralized infrastructure, many practical AI use cases are emerging at the edge. Manufacturing quality control, predictive maintenance, healthcare monitoring, and industrial automation all benefit from local inference and real-time decision making. These workloads require platforms capable of managing both infrastructure and applications across thousands of distributed locations. We believe this convergence of AI and edge computing will be one of the defining infrastructure trends of the coming years. ## The validation of a direction Vyshak, Principal Analyst at QKS Group described Kubermatic as: > ***"particularly well suited for organizations prioritizing workload portability, operational efficiency, and long-term infrastructure flexibility across edge, hybrid cloud, and regulated environments"*** The analyst's assessment reinforces something we've believed for a long time: the future of Edge Kubernetes will be shaped by automation, operational resilience, infrastructure flexibility, and sovereignty. Those are the areas we've been investing in for years, and they're the areas we'll continue to focus on. We're thankful to our customers, partners, and the open source community for helping shape that direction. And we're looking forward to continuing the work. ## Learn more - Discover more about the [SPARK Matrix™: Edge Kubernetes Platforms, Q3 2026](/leader-in-spark-matrix-edge-kubernetes-platforms/) - Explore [Kubermatic for Edge](/solutions/edge-computing/) - Learn about our approach to [sovereign infrastructure](/solutions/control-your-data-sovereignty/) --- ## Kubermatic positioned as a Leader in the SPARK Matrix TM: Edge Kubernetes Platforms - **URL:** https://www.kubermatic.com/leader-in-spark-matrix-edge-kubernetes-platforms/ - **Date:** 2026-07-07 - **Description:** Discover SPARK Matrix™: Edge Kubernetes Platforms, Q3 2026 where Kubermatic got named as a Leader. # SPARK Matrix™: Edge Kubernetes Platforms, Q3 2026 ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Kubermatic Named a SPARK Leader by QKS Group [![SPARK Matrix™: Edge Kubernetes Platforms, Q3 2026](/static/spark-matrix-edge-kubernetes-platforms-q3-2026-img.png)](/static/spark-matrix-edge-kubernetes-platforms-q3-2026-img.png "See expanded version of SPARK Matrix™: Edge Kubernetes Platforms, Q3 2026 chart") QKS Group has recognized Kubermatic as a **SPARK Leader** in the SPARK Matrix™: Edge Kubernetes Platforms, Q3 2026. The SPARK Matrix™ evaluates leading Edge Kubernetes Platform providers based on two core dimensions: **Technology Excellence** and **Customer Impact**. In the latest evaluation, Kubermatic was positioned among the five SPARK Leaders recognized in the market. This evaluation is particularly relevant for platform teams, infrastructure architects, edge computing leaders, and IT decision-makers responsible for deploying and operating Kubernetes across distributed edge environments. ## Why the QKS Group Recognized Kubermatic ![Kubermatic named a SPARK Leader badge](/static/spark-matrix-2026-kubermatic-as-a-leader-badge.png) > "Kubermatic differentiates itself through its highly scalable Kubernetes-in-Kubernetes architecture, full-stack automation support, and strong commitment to open, infrastructure-neutral operations. > > The platform's ability to unify virtual machines and containers, (...) operational autonomy for disconnected environments, and **early investments in AI-native operations** (...) positions Kubermatic strongly for enterprises seeking to build sovereign, distributed cloud environments at scale. > > Its architecture is particularly well suited for organizations prioritizing workload portability, operational efficiency, and long-term infrastructure flexibility across edge, hybrid cloud, and regulated environments." — Vyshak, Principal Analyst at QKS Group **Key capabilities highlighted in the SPARK Matrix™ include**: - Kubernetes lifecycle automation at scale - Hybrid, edge, and sovereign cloud deployments - Infrastructure neutrality - Workload portability across distributed environments - Operational autonomy for disconnected edge locations - AI-native operations through K8sGPT and MCP integration - Unified management of virtual machines and containers - Explore our perspective on the trends shaping edge Kubernetes and the recognition from QKS. ## Interested in building and operating Kubernetes at the edge? [Discover Kubermatic for Edge](/solutions/edge-computing/) ## What is the SPARK Matrix™? The SPARK Matrix™ is QKS Group's vendor evaluation framework that compares technology providers based on Technology Excellence and Customer Impact. The SPARK Matrix™: Edge Kubernetes Platforms, Q3 2026 evaluated 10 leading vendors in the market and recognized 5 vendors as SPARK Leaders and 5 vendors as Strong Contenders. [Learn more in our FAQ](/topics/spark-matrix/) ## Our Upcoming Events [![Proud partner of WeAreDevelopers World Congress Europe, 8-10 July, Berlin](/static/event-wearedevelopers26_hu_1cbbc2a6515d782.jpg)](https://www.wearedevelopers.com/) Onsite Conference ## [Join us in Berlin at WeAreDevelopers](https://www.wearedevelopers.com/) [Join Here](https://www.wearedevelopers.com/) [![](/static/containerdays-hamburg-2026_hu_d4a7201e201462bf.jpg)](https://www.containerdays.io/containerdays-hamburg-2026/) Onsite Conference ## [ContainerDays Hamburg is Back in the Harbor of Hamburg for 2026!](https://www.containerdays.io/containerdays-hamburg-2026/) [Join Here](https://www.containerdays.io/containerdays-hamburg-2026/) ## Ready to try Kubermatic Kubernetes Platform? [Get Your Free Demo](/demo/) --- ## Meet Kubermatic Virtualization 1.2 - Run, Protect, and Scale - **URL:** https://www.kubermatic.com/blog/meet-kubermatic-virtualization-1-2-run-protect-and-scale/ - **Date:** 2026-07-06 - **Description:** Built-in identity and access management (IAM), dashboard-driven networking, and a more reliable operational foundation that powers the entire platform. - **Categories:** Company - **Tags:** KubeV - **Authors:** Csenger Szabo We're excited to announce Kubermatic Virtualization (KubeV) 1.2. This release introduces three of the most requested capabilities from our community: built-in identity and access management (IAM), dashboard-driven networking, and a more reliable operational foundation that powers the entire platform. Behind the scenes, KubeV 1.2 improves how the platform manages its own resources. Networking, IAM, and other platform objects now follow a consistent reconciliation model, allowing the platform to automatically detect and correct drift while keeping resources aligned with their desired state. This translates into greater reliability today and a stronger foundation for future features. ## What's New in KubeV 1.2 ### Advanced Networking from the Dashboard Managing virtual networks no longer requires editing YAML or using the CLI. KubeV 1.2 lets you create and manage both overlay and underlay networking directly from the dashboard. Platform networking resources-including VPCs, subnets, security groups, NAT gateways, and elastic IPs-are now reconciled by the new dedicated controller manager. This means networking changes are declarative, resilient, and automatically brought back to the desired state whenever necessary. ### Built-In IAM & Fine-Grained Access Control <img src="/static/kubev-access-management-system.png" alt="Kubermatic Virtualization Access Management Dashboard" width="800" height="326" loading="lazy" style="display:block;height:auto;margin:20px auto;"> KubeV now includes a native Identity and Access Management system with a built-in Administration panel. Administrators can manage users, roles, and permissions without leaving the platform. Two system roles are available out of the box: - **admin** - full administrative access - **viewer** - read-only access Beyond these defaults, you can define custom roles with fine-grained permissions based on resource groups and allowed actions, then assign them through role bindings. <img src="/static/kubev-role-management.png" alt="Kubermatic Role Management Settings" width="800" height="415" loading="lazy" style="display:block;height:auto;margin:20px auto;"> Like networking, IAM is built on the new controller-manager architecture. Roles, bindings, and permissions are stored as Kubernetes resources and continuously reconciled, allowing permission changes to take effect immediately without requiring users to restart sessions or log in again. IAM is fully supported when KubeV is configured with OIDC authentication. ### Permission-Aware Kubeconfigs Users can now download a personal kubeconfig that's automatically tied to a dedicated ServiceAccount. The permissions available through kubectl directly mirror the permissions assigned through the KubeV IAM system, eliminating the need to manually configure Kubernetes RBAC separately and ensuring consistent access across both the UI and CLI. ### Smoother Installation & Upgrades We've streamlined both installation and upgrade workflows to improve reliability and reduce the operational effort required to keep clusters up to date. ### More Reliable Live Migration We've addressed several issues affecting virtual machine live migration, significantly improving migration success rates while increasing overall cluster stability during maintenance and workload movement. ### Secure-by-Default Network Policies KubeV now ships with sensible default network policies that enforce workload isolation from the moment a cluster is created, providing a stronger security posture without additional configuration. ### Simplified Node-Level Kubelet Configuration Host kubelet configuration can now be managed directly through configuration files, making it easier to operate and standardize larger node fleets. ## Why it Matters Managing a virtualization platform shouldn't require choosing between operational simplicity and enterprise-grade security. KubeV 1.2 delivers both. Built-in IAM and permission-aware kubeconfigs provide a consistent security model across the dashboard and kubectl. Dashboard-based networking simplifies infrastructure management without sacrificing flexibility. Underneath these capabilities, the new controller manager continuously reconciles platform resources, making the platform more resilient, self-healing, and easier to operate as your environment grows. This controller-based architecture also lays the groundwork for future platform capabilities, allowing new resource types and services to integrate into the same declarative management model. Whether you're building a private cloud from scratch or modernizing an existing virtualization platform, Kubermatic Virtualization gives you the tools to deploy, secure, and scale workloads with confidence. ## Get Started Today Learn more about Kubermatic Virtualization 1.2 and start deploying today by visiting the [documentation](https://docs.kubermatic.com/kubermatic-virtualization/v1.2.0/). --- ## Rethinking How Automation is Built: A Guide to Software Defined Automation (SDA) - **URL:** https://www.kubermatic.com/resources/software-defined-automation/ - **Date:** 2026-07-07 - **Description:** Discover how Software Defined Automation (SDA) separates software from hardware to reduce time to market, improve scalability, and simplify industrial automation. # Rethinking How Automation is Built: A Guide to Software Defined Automation (SDA) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Whitepaper This whitepaper, published by the Open Industry 4.0 Alliance, introduces the concept of Software Defined Automation (SDA). SDA represents a shift in how automation systems are designed, advocating for building automation around software rather than tightly coupling applications to specific devices. By decoupling software from physical hardware, systems can avoid fragmented landscapes and complex integrations. [Download](/static/Software-Defined-Automation-Whitepaper.pdf) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Protecting Your Kubernetes Applications with KubeLB's Web Application Firewall - **URL:** https://www.kubermatic.com/blog/protecting-kubernetes-applications-with-kubelb-web-application-firewall/ - **Date:** 2026-07-02 - **Description:** Block SQL injection, XSS, and the OWASP Top 10 at the gateway with KubeLB's Web Application Firewall. A practical guide to WAFPolicy targeting, tuning, and a live demo. - **Categories:** Best Practices - **Tags:** KubeLB, Security - **Authors:** Abubakar Siddiq Ango Every application you expose to the internet is a target. SQL injection, cross-site scripting, and command injection have sat near the top of the [OWASP Top 10](https://owasp.org/Top10/2025/0x00_2025-Introduction/) for years, and they arrive as ordinary-looking HTTP requests aimed at whatever serves your traffic. In Kubernetes, that traffic increasingly arrives through the [Gateway API](https://gateway-api.sigs.k8s.io/), the standard successor to Ingress for routing external requests to your services. You define a `Gateway` for the entry point and `HTTPRoute` resources for the paths and hosts behind it, and requests flow to the right pods. Gateway API is very good at getting each request to the right place. Inspecting that request for malicious content is a separate concern, and it is where a Web Application Firewall comes in: nothing in a route stops it from forwarding `?id=1' OR '1'='1` straight to your database-backed service. KubeLB's Web Application Firewall (WAF), [introduced in v1.3](https://www.kubermatic.com/blog/kubelb-v1-3-advanced-security-with-waf-seamless-gateway-api-migration-and-supply-chain-integrity/) and [promoted to Beta in v1.4](https://www.kubermatic.com/blog/introducing-kubelb-1-4-a-new-dashboard-air-gap-ready-deployments-and-hardened-multi-tenancy/), adds that inspection at the gateway level, protecting your `HTTPRoute` and `GRPCRoute` resources with no application changes required. ## Why WAF at the Gateway? Most teams handle application security in one of two ways. They leave it to developers, who have other priorities, or they bring in a dedicated WAF, either a cloud provider's managed offering or a third-party appliance. A dedicated WAF does the job, and it comes with a bill: cloud WAFs charge per rule and per million requests, third-party appliances add licensing, and both are another layer to operate. Those costs grow with your traffic. A gateway-level WAF shifts security from individual applications to infrastructure, and it removes that separate bill. KubeLB runs the WAF inside the Envoy proxy it already uses for load balancing, so there is no dedicated appliance to license and no per-request charge from a cloud WAF. Platform teams define policies once, every route gets protected automatically, and developers don't need to think about SQL injection filters. The gateway handles it before traffic reaches their services. This is especially relevant if you've recently [migrated from Ingress NGINX to Gateway API](https://docs.kubermatic.com/kubelb/v1.4/ingress-to-gateway-api/). Your routes are modern now. The next step is making sure they're protected. ## How KubeLB WAF Works Under the hood, KubeLB WAF uses the [Coraza WASM filter](https://github.com/corazawaf/coraza-proxy-wasm), an open-source, OWASP-maintained Web Application Firewall that runs inside Envoy proxy as a WebAssembly plugin. It ships with the [OWASP Core Rule Set (CRS)](https://coreruleset.org/), a battle-tested collection of rules that protect against the most common web exploits. The architecture is straightforward: 1. KubeLB already uses Envoy proxy for load balancing 2. WAF adds a Coraza WASM filter to the Envoy pipeline 3. HTTP requests are inspected against OWASP CRS rules *before* reaching your application 4. Malicious requests get blocked (or logged, if you're in detection mode) It runs inside the same Envoy proxy that already handles your traffic, with no sidecars and no separate appliance to operate. ## Getting Started ### Enable WAF WAF is disabled by default. Enable it in your KubeLB manager's `values.yaml`: ```yaml kubelb: enableWAF: true ``` ### Your First WAFPolicy KubeLB WAF is configured through the `WAFPolicy` custom resource. The simplest way to protect a route: ```yaml apiVersion: kubelb.k8c.io/v1alpha1 kind: WAFPolicy metadata: name: protect-my-app spec: targetRef: kind: HTTPRoute name: my-app ``` That's it. When you don't specify any `directives`, KubeLB applies the OWASP CRS defaults: full blocking mode with a 12.5MB request body limit. Under the hood, this translates to: ```text SecRuleEngine On SecRequestBodyAccess On SecRequestBodyLimit 13107200 Include @crs-setup-conf Include @owasp_crs/*.conf ``` Your route is now protected against SQL injection, XSS, command injection, and the rest of the OWASP Core Rule Set, with zero rule writing on your part. ## Three Ways to Target Routes WAFPolicy supports three targeting strategies, depending on how broadly you want to apply protection: ### 1. Specific Route (targetRef) Protect a single named route. Highest precedence. ```yaml spec: targetRef: kind: HTTPRoute name: my-app namespace: production ``` ### 2. Label-Based (targetSelector) Protect all routes matching a label. Great for multi-tenant setups. ```yaml spec: targetSelector: matchLabels: kubelb.k8c.io/tenant-name: tenant-a ``` Or match multiple tenants: ```yaml spec: targetSelector: matchExpressions: - key: kubelb.k8c.io/tenant-name operator: In values: ["tenant-a", "tenant-b"] ``` ### 3. Global Protect every HTTPRoute and GRPCRoute in the cluster. Lowest precedence, so specific policies override it. ```yaml spec: global: true ``` When multiple policies apply to the same route, precedence goes: `targetRef` > `targetSelector` > `global`. Within the same level, the oldest policy (by creation timestamp) wins; if two policies share a creation timestamp, the alphabetically-first name applies. ## See It In Action Here is the WAF running against a live route. The clip walks through the config files, sends a legitimate request, then a spread of real attacks, and shows each one returning 200 or 403. It ends with a paranoia-level change that flips Remote File Inclusion from allowed to blocked. <iframe src="https://www.youtube.com/embed/nvJ3a8hqHBY" title="Protecting Your Kubernetes Applications with KubeLB's Web Application Firewall" style="width:100%;aspect-ratio:1749/1154;height:auto;border:0;" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe> ## Tuning the Paranoia Level The CRS defaults are deliberately conservative to keep false positives low, so some attack classes only trip at higher paranoia levels. Remote File Inclusion is the example in the clip above: at the default level, a bare off-domain URL in a parameter passes through. Raise the CRS paranoia level to 2 with a single directive, and the same request is blocked while the legitimate request still passes: ```yaml apiVersion: kubelb.k8c.io/v1alpha1 kind: WAFPolicy metadata: name: strict-waf spec: global: true directives: - "SecRuleEngine On" - "SecRequestBodyAccess On" - 'SecAction "id:900000,phase:1,nolog,pass,t:none,setvar:tx.blocking_paranoia_level=2"' - "Include @crs-setup-conf" - "Include @owasp_crs/*.conf" ``` The RFI request now returns `403`; the legitimate search request still returns `200`. Higher paranoia levels catch more at the cost of more false positives. That is the classic security trade-off, and the paranoia level is the dial. Start at the default, watch your logs (detection mode helps here), and raise it where your risk tolerance calls for it. ## Pair With NetworkPolicies for Defense in Depth WAF inspects HTTP traffic at L7, stopping SQL injection, XSS, and the rest of the OWASP Top 10 before requests reach your application. But L7 inspection alone doesn't stop one tenant's pod from talking directly to another tenant's services over the pod network. KubeLB v1.4 added Kubernetes NetworkPolicies that complement WAF with L3/L4 isolation between tenant namespaces. Operators can configure them at the Global or Tenant level, and they sit alongside KubeLB's existing namespace-per-tenant model. The two layers work together: NetworkPolicies enforce *who can talk to whom*, WAF enforces *what they're allowed to say*. For regulated and multi-tenant environments, you want both. ## Start with Detection Mode Turning on a WAF in blocking mode on day one is risky, because legitimate requests can get caught by rules that are too aggressive for your traffic patterns. KubeLB supports a detection-only mode that logs violations without blocking: ```yaml apiVersion: kubelb.k8c.io/v1alpha1 kind: WAFPolicy metadata: name: detect-only spec: targetRef: kind: HTTPRoute name: my-app directives: - "SecRuleEngine DetectionOnly" - "SecRequestBodyAccess On" - "Include @crs-setup-conf" - "Include @owasp_crs/*.conf" ``` Run this for a few days, review the logs for false positives, tune your rules, then switch to `SecRuleEngine On` when you're confident. ## Developer Self-Service Pattern The `targetSelector` mode supports a self-service workflow. A platform team pre-creates a WAFPolicy that matches a label, and developers opt their routes in by setting that label on them. **Platform team creates the policy once:** ```yaml apiVersion: kubelb.k8c.io/v1alpha1 kind: WAFPolicy metadata: name: standard-waf spec: targetSelector: matchLabels: security.kubelb.io/waf: enabled ``` **Developers enable WAF on their route:** ```yaml apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: my-app labels: security.kubelb.io/waf: enabled spec: # ... route config ``` Developers opt in by adding one label, without needing access to create or change WAF policies. The platform team owns the policy and its rules, and each team decides which of their own routes it covers. ## Custom Rules The OWASP CRS defaults work for most applications. But if you need custom rules (maybe to block a specific attack pattern or protect a gRPC service differently), you can write SecLang directives directly: ```yaml apiVersion: kubelb.k8c.io/v1alpha1 kind: WAFPolicy metadata: name: grpc-waf spec: targetRef: kind: GRPCRoute name: my-grpc-service namespace: production directives: - "SecRuleEngine On" - "SecRequestBodyAccess Off" - 'SecRule REQUEST_HEADERS "@detectSQLi" "id:900001,phase:1,deny,status:403,msg:SQLi in header"' ``` SecLang is the same directive syntax used by ModSecurity, so existing ModSecurity rules port over directly. ## Monitoring KubeLB exposes Prometheus metrics for WAF: | Metric | What It Tells You | |--------|------------------| | `kubelb_manager_waf_policies` | How many valid/invalid policies exist | | `kubelb_manager_waf_routes_protected` | How many routes have active WAF | | `kubelb_manager_waf_routes_blocked` | Routes blocked by fail-closed policies | | `kubelb_manager_waf_filter_failures_total` | Filter creation failures | | `kubelb_manager_waf_policy_reconcile_total` | Policy reconciliation attempts | | `kubelb_manager_waf_policy_reconcile_duration_seconds` | How long policy reconciliation takes | These give you visibility into WAF coverage and health across your cluster. KubeLB v1.4 also ships a web-based Dashboard that browses tenants, LoadBalancers, Routes, and WAFPolicies in one place, so you can see policy coverage at a glance. ## Things to Know **Beta status.** WAF was promoted to Beta in KubeLB v1.4. The API is stabilizing, but minor changes are still possible before GA. **Enterprise Edition only.** WAF requires KubeLB Enterprise Edition. **Air-gap friendly.** The OWASP CRS rules ship inside the bundled images, so WAF works in fully offline installs alongside KubeLB v1.4's mirror-registry support. **L7 only.** WAF inspects HTTP traffic, so it protects HTTPRoute and GRPCRoute resources. L4 traffic (LoadBalancer services, TCPRoute, UDPRoute, TLSRoute) passes through without WAF inspection. **Connection behavior.** When you update a WAFPolicy, new connections pick up the changes immediately. But existing HTTP/2 or keep-alive connections continue using the old config until they close (typically after a 60-second idle timeout). To force a fresh connection for testing: ```bash curl -H "Connection: close" https://your-app.example.com/test ``` ## What's Next KubeLB WAF gives platform teams a way to protect Gateway API routes from common web exploits, without touching application code, adding sidecars, or managing a separate WAF appliance. Start in detection mode, review the logs, and move to blocking when you're ready. **Learn more:** - [KubeLB WAF Tutorial](https://docs.kubermatic.com/kubelb/v1.4/tutorials/web-application-firewall/) - [OWASP Core Rule Set](https://coreruleset.org/) - [Coraza WAF Project](https://github.com/corazawaf/coraza) - [KubeLB v1.4 Release Announcement](https://www.kubermatic.com/blog/introducing-kubelb-1-4-a-new-dashboard-air-gap-ready-deployments-and-hardened-multi-tenancy/) --- ## SPARK Matrix™ - **URL:** https://www.kubermatic.com/topics/spark-matrix/ - **Date:** 2026-07-07 - **Description:** The SPARK Matrix™ is a framework by QKS Group that provides a visual competitive analysis of top technology vendors within a specific market. Vendors are measured against two key areas: Technology Excellence and Customer Impact. # SPARK Matrix™: Edge Kubernetes Platforms, Q3 2026 ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Jump To Section [What is the QKS Group?](#what-is-the-qks-group) [What is the SPARK Matrix™?](#what-is-the-spark-matrix) [What does the SPARK Matrix™: Edge Kubernetes Platforms cover?](#what-does-the-spark-matrix-edge-kubernetes-platforms-cover) [How many vendors are included?](#how-many-vendors-are-included) [Why was Kubermatic included?](#why-was-kubermatic-included) [Where can I see the SPARK Matrix™: Edge Kubernetes Platforms graph](#where-can-i-see-the-spark-matrix-edge-kubernetes-platforms-graph) ## What is the QKS Group? QKS Group, formerly Quadrant Knowledge Solutions, is a global research and advisory firm that helps organizations make data-driven decisions. The firm analyzes technology markets, evaluates vendors and solutions to help businesses identify leading solutions and make informed purchasing decisions. ## What is the SPARK Matrix™? The SPARK Matrix™ is QKS Group’s vendor evaluation framework to compare technology vendors and their solutions. It typically evaluates vendors based on two dimensions: - **Technology Excellence**: how strong and capable a vendor’s product or technology is (for example: features, innovation, roadmap, scalability, integrations, and overall product capabilities). - **Customer Impact**: how well the vendor delivers value to customers (for example: customer satisfaction, adoption, service quality, business outcomes, and market reputation). Vendors are then positioned on a matrix (often including SPARK Leaders, Strong Contenders and Aspirants), to provide a visual comparison of the competitive landscape. ## What does the SPARK Matrix™: Edge Kubernetes Platforms cover? The **SPARK Matrix™: Edge Kubernetes Platforms** evaluates vendors that provide Kubernetes platforms designed to support distributed, edge, hybrid, and sovereign cloud environments. The report analyzes how these platforms enable organizations to deploy, manage, automate, and operate Kubernetes infrastructure across diverse locations, including edge sites, on-premises environments, and cloud infrastructures. The evaluation focuses on key capabilities such as Kubernetes lifecycle management, automation, scalability, workload portability, infrastructure flexibility, disconnected operations, virtualization support, AI-driven operations, and edge-specific use cases. ## How many vendors are included? The latest **SPARK Matrix™: Edge Kubernetes Platforms, Q3 2026** evaluated 10 leading vendors in the global Edge Kubernetes Platform market. The evaluation classified 5 vendors as SPARK Leaders and 5 vendors as Strong Contenders. ## Why was Kubermatic included? Kubermatic was recognized as a **SPARK Leader** in the **QKS Group SPARK Matrix™: Edge Kubernetes Platforms, Q3 2026**, positioning the company among the 10 top-performing vendors globally. QKS Group evaluated Kubermatic highly across both **Technology Excellence** and **Customer Impact**, recognizing our ability to deliver scalable, automated, and infrastructure-neutral Kubernetes operations across edge, hybrid cloud, and sovereign environments. The QKS Group highlighted: “*Kubermatic differentiates itself through its highly scalable Kubernetes-in-Kubernetes architecture, full-stack automation support, and strong commitment to open, infrastructure-neutral operations”* The analyst also recognized Kubermatic’s ability to unify virtual machines and containers, enable operational autonomy in disconnected environments, and support workload portability through capabilities such as **KubeLB**, **K8sGPT**, and **MCP integration**. According to Vyshak, Principal Analyst at QKS Group: *“Kubermatic’s architecture is particularly well suited for organizations prioritizing workload portability, operational efficiency, and long-term infrastructure flexibility across edge, hybrid cloud, and regulated environments.”* ## Where can I see the SPARK Matrix™: Edge Kubernetes Platforms graph You can view the visual comparison of the competitive landscape right here: [![SPARK Matrix™: Edge Kubernetes Platforms, Q3 2026](/static/spark-matrix-edge-kubernetes-platforms-q3-2026-img.png)](/static/spark-matrix-edge-kubernetes-platforms-q3-2026-img.png "See expanded version of SPARK Matrix™: Edge Kubernetes Platforms, Q3 2026 chart") Discover more about the [SPARK Matrix™: Edge Kubernetes Platforms, Q3 2026](/leader-in-spark-matrix-edge-kubernetes-platforms/) --- ## The Anthropic shutdown: a wake-up call for European digital sovereignty - **URL:** https://www.kubermatic.com/blog/the-anthropic-shutdown-a-wake-up-call-for-european-digital-sovereignty/ - **Date:** 2026-06-18 - **Description:** The US government disrupted access to Anthropic's most advanced AI models. Here's what it means for European digital sovereignty and enterprise AI strategy. - **Categories:** Community - **Tags:** Announcements, Best Practices - **Authors:** Abubakar Siddiq Ango On Friday 12 June, Anthropic [disabled its two most capable models](https://www.anthropic.com/news/fable-mythos-access), Fable 5 and Mythos 5, for every customer worldwide. The company had received a [US government directive](https://www.aljazeera.com/news/2026/6/13/us-orders-anthropic-to-disable-ai-models-for-all-foreign-nationals) to suspend access for any foreign national, inside or outside the United States (including foreign employees working inside Anthropic's US office). With no reliable way to separate foreign nationals from US persons across hundreds of millions of users on same-day notice, the only way to comply was to turn the models off for everyone - US and European commercial customers alike. The security bureaucracy cited vague national security concerns regarding a potential "jailbreak" method related to code review capabilities. Anthropic says it received only verbal notice of a "potential narrow, non-universal" issue with no specific national-security detail in the letter. Anthropic [disagreed with the order](https://www.aljazeera.com/news/2026/6/13/us-orders-anthropic-to-disable-ai-models-for-all-foreign-nationals), stated that the safety measures involved had been extensively tested, but had to comply anyway. The mechanism is now on the record: a single government can issue a same-day directive and disrupt access to a globally critical AI service. ## What this means for your business Private enterprises are now caught in the crossfire of political disputes between US tech vendors and Washington's defense bureaucracy. You have no say, no vote, and no legal recourse when these decisions are made. This incident proves that "the cloud" is ultimately bound by geography and national jurisdiction. Because the underlying technology is governed by US jurisdiction, the US government holds a unilateral kill switch over global commercial operations. The incident also highlights a growing divergence between regulatory approaches. European organisations are moving toward a predictable framework through the EU AI Act, while the US relies more heavily on national security interventions. Operating a predictable business that depends on both systems is becoming increasingly difficult. ## It all comes down to sovereignty This is the sovereignty argument that has worked its way up the stack for a decade, arriving now at the model layer. It began with data residency. Choosing a European region put data in Frankfurt, but the US [CLOUD Act](https://www.congress.gov/crs-product/R45173) still reached it, because jurisdiction follows the legal entity that controls the keys, not the building where it sits. It moved to silicon, where a fabrication plant on European soil remains subject to US export rules if it depends on US design tools. More recently, it reached the agentic control plane, where the gateway every AI agent passes through is, by default, a managed service inside a hyperscaler. The model is the highest and most expensive layer of that stack. Yet, until last week, it was the one most enterprises thought about the least. An organisation can self-host its databases, operate its own Kubernetes platform, and run its own agent gateway, yet still depend entirely on a model it can access only through a foreign-jurisdiction API. The Fable 5 shutdown showed what that dependency costs when the jurisdiction decides to act. ## The decision in front of you Ask yourself a simple question: if a foreign supplier stopped serving your organisation tomorrow morning, could you keep operating? For many AI deployments, the answer is no. The Anthropic shutdown established something important: the off switch exists. If a government can withdraw access to a critical service without warning, then that dependency is a business risk. The response is to regain control. Map the parts of your AI stack that depend on providers, gateways, or models you cannot run yourself. Then build a sovereign architecture around them. That means: infrastructure you operate, under laws you understand, with no external party able to switch it off. Sovereignty should be treated the same way organisations already treat security and resilience: as an architectural requirement. This is the foundation we help organisations build at Kubermatic. Our platform enables enterprises to run and manage AI workloads on infrastructure they control across on-premises, private cloud, and hybrid environments, reducing dependence on foreign-controlled platforms and services. If sovereign AI is on your roadmap, our [Sovereignty Solution Brief](/solutions/control-your-data-sovereignty/) explains the practical steps required to build and operate AI infrastructure that remains under your organisation's control. --- ## Kubermatic Replaces VMware with Open Source Virtualization on Kubernetes - **URL:** https://www.kubermatic.com/resources/kubermatic-replaces-vmware-with-open-source-virtualization-on-kubernetes/ - **Date:** 2026-06-17 - **Description:** Discover why enterprises are transitioning away from VMware after Broadcom's acquisition and how KubeVirt-based platforms offer a seamless path to open-source virtualization on Kubernetes. # Kubermatic Replaces VMware with Open Source Virtualization on Kubernetes ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Mo'ath Qasim talk on the SoftwarePlaza Podcast Following Broadcom’s acquisition of VMware, organizations are facing skyrocketing pricing and unpredictable licensing changes, prompting them to look for alternative exit strategies. In this episode of the SoftwarePlaza Podcast, Mo’ath Qasim, VP of Engineering at Kubermatic, explains how enterprises can run legacy virtual machines side-by-side with modern containers on a unified platform. The discussion provides an in-depth tour of the Kubermatic Virtualization dashboard, highlights the technical challenges of matching advanced network architectures like VLANs and BGP, and breaks down the automated migration tooling used to transition workloads seamlessly off traditional hypervisors. **Key Takeaways**: - **Scaling & Automation**: How Kubernetes provides the ultimate engine and control plane to provision, manage, and scale thousands of traditional VMs. - **Unified Infrastructure**: Bridging the gap between legacy virtual machines and modern containers to break down IT engineering silos. - **Data Sovereignty & Security**: Eliminating proprietary vendor lock-in through 100% open-source, KubeVirt-compatible technology stacks that keep organizations fully sovereign. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## How KubeLB Runs Your Agent Gateway - **URL:** https://www.kubermatic.com/blog/how-kubelb-runs-your-agent-gateway/ - **Date:** 2026-06-23 - **Description:** KubeLB v1.4 deploys and manages an agent gateway on your own clusters, using the open-source agentgateway data plane for LLM, MCP, and agent-to-agent traffic. - **Categories:** Best Practices - **Tags:** KubeLB, AI Infrastructure, Agentic AI, MCP, Kubernetes, Gateway API, Open Source Projects - **Authors:** Abubakar Siddiq Ango When you run AI agents, almost everything they do crosses one piece of infrastructure. The tools an agent calls, the model requests behind its reasoning, the messages it sends to other agents — all of it flows through a gateway. That gateway can see what your agents do and decide what they are allowed to do, which makes it the most sensitive control point in an agentic system. So the practical question is where it runs, and who operates it. If you already run [KubeLB](https://www.kubermatic.com/products/kubelb/), the answer is already in place. KubeLB v1.4 deploys and manages an agent gateway for you, on your own clusters, using the open-source [agentgateway](https://agentgateway.dev/) project as the data plane. ## What KubeLB does KubeLB is Kubermatic's Kubernetes-native, multi-tenant load balancer. It centralizes Layer 4 and Layer 7 load balancing for a fleet of clusters using a hub-and-spoke model. A **management cluster** runs the data plane (Envoy) and a central control plane. Each **tenant cluster** runs a lightweight agent that propagates its load-balancing config up to the management cluster through KubeLB's CRDs. Tenants never touch the management cluster directly — they declare what they need, and KubeLB provisions and configures the data plane for them. KubeLB is built on the Kubernetes Gateway API. An agent gateway is really just a Gateway API data plane that also understands AI traffic, which is why it fits into KubeLB so cleanly. ## What the agent gateway is [agentgateway](https://agentgateway.dev/) is an open, Envoy-based data plane that implements the Kubernetes Gateway API and adds first-class support for three kinds of agentic traffic: - **LLM traffic** — routing model requests to providers (OpenAI, Anthropic, Google, Mistral, or local models), with the auth, rate limiting, and observability you would expect from a gateway. - **MCP servers** — federating one or more Model Context Protocol servers behind a single endpoint, so an agent reaches your tools through one governed entry point. - **Agent-to-agent (A2A)** — proxying traffic between agents through the same gateway, so agent-to-agent calls get the same policy and visibility as everything else. It recently joined the Linux Foundation's [Agentic AI Foundation](https://aaif.io/blog/agentgateway-joins-aaif-as-an-open-gateway-for-agentic-ai-infrastructure/) (AAIF), the same independent home as MCP. So the data plane carrying your agents' authority to act is open source and governed by a neutral foundation. For the concept on its own — why agentic traffic needs its own gateway, and the main use cases — see [What Is an Agent Gateway?](https://www.kubermatic.com/blog/what-is-an-agent-gateway/). ## How it works in KubeLB In KubeLB v1.4, the agent gateway ships as an [addon in the KubeLB manager chart](https://docs.kubermatic.com/kubelb/v1.4/installation/management-cluster/) — the same `kubelb-addons` mechanism KubeLB uses for components like cert-manager and the Gateway API. You enable it in the manager chart values, and the management cluster deploys and runs it: ```yaml kubelb: enableGatewayAPI: true kubelb-addons: enabled: true agentgateway: enabled: true ``` From there you configure it with standard Gateway API resources plus one agentgateway CRD. First, a `Gateway` that uses the `agentgateway` GatewayClass: ```yaml apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: agentgateway-proxy namespace: kubelb spec: gatewayClassName: agentgateway listeners: - name: http protocol: HTTP port: 8080 allowedRoutes: namespaces: from: All ``` Then an `AgentgatewayBackend` that describes where the traffic actually goes — here, a self-hosted open model exposed through an OpenAI-compatible API, with its credentials pulled from a secret: ```yaml apiVersion: agentgateway.dev/v1alpha1 kind: AgentgatewayBackend metadata: name: local-llm namespace: kubelb spec: ai: provider: # Point at any OpenAI-compatible server. Here it is a self-hosted open # model (llama.cpp, vLLM, or Ollama) running in the cluster. host: llama-cpp.llm.svc.cluster.local port: 8080 openai: model: gemma-4-12b-it policies: auth: secretRef: name: llm-secret ``` And an `HTTPRoute` that points a path at that backend: ```yaml apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: local-llm namespace: kubelb spec: parentRefs: - name: agentgateway-proxy namespace: kubelb rules: - backendRefs: - name: local-llm namespace: kubelb group: agentgateway.dev kind: AgentgatewayBackend ``` Those three resources are the whole pattern. The Gateway listens, the `AgentgatewayBackend` defines the LLM target and its credentials, and the `HTTPRoute` connects them. Agents send their requests to the gateway, which handles auth, routing, and policy before forwarding them on. The MCP and A2A cases follow the same pattern. For MCP, the backend describes a set of `mcp.targets` — several MCP servers federated behind one endpoint — and a route exposes them under an `/mcp` path. For A2A, agentgateway proxies traffic between agents through the same gateway, so those calls inherit the same auth and observability. The full, tested walkthrough — including a request test, rate limiting, and MCP setup — is in the [KubeLB AI & MCP Gateway tutorial](https://docs.kubermatic.com/kubelb/v1.4/tutorials/aigateway/). ## Why running it on KubeLB matters Because the gateway is a KubeLB addon, two things come for free. First, it is **multi-tenant by design**. The same management cluster that load-balances your fleet now provisions agent gateways across it, with the tenant isolation KubeLB already enforces. You are not standing up and operating a separate gateway per team or per cluster by hand. Second, it runs on **infrastructure you operate**. The fastest path to an agent gateway is usually the managed one a cloud provider offers, but that puts the control point for your agents inside a platform you don't run. Running it on KubeLB keeps it on your own clusters, on a data plane that is open source and governed by a neutral foundation. That placement is hard to change later — once every agent in the company depends on a gateway, moving it is a migration — so it is worth choosing on purpose while it is still easy. ## Takeaways - The agent gateway is the control point for agentic systems — every tool call, model request, and agent-to-agent message passes through it. - KubeLB v1.4 ships one as a managed addon, using the open-source agentgateway data plane (Envoy, Gateway API, now in the LF Agentic AI Foundation). - It covers LLM routing, MCP federation, and A2A through standard Gateway API resources plus the `AgentgatewayBackend` CRD. - Because it is part of KubeLB, you get it multi-tenant across your fleet and on infrastructure you control. Try it: the [KubeLB AI & MCP Gateway tutorial](https://docs.kubermatic.com/kubelb/v1.4/tutorials/aigateway/) walks through the full setup. To build an agent gateway from the ground up, the [AI Infrastructure track on Kubermatic Learn](https://www.kubermatic.com/learn/ai-infrastructure/) covers it step by step. --- ## Installing OpenBao on Kubernetes - **URL:** https://www.kubermatic.com/learn/security/installing-openbao-kubernetes/ - **Date:** 2026-06-17 [Learn](/learn/) / [Security](/learn/security/) / Installing OpenBao on Kubernetes security # Installing OpenBao on Kubernetes ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Jun 17, 2026 2 min read Beginner [getting-started](/learn/?tag=getting-started) [security](/learn/?tag=security) [secrets-management](/learn/?tag=secrets-management) [openbao](/learn/?tag=openbao) #### Prerequisites - A Kubernetes cluster (this tutorial uses a local kind cluster) - kubectl installed and configured - Helm 3.6+ installed - Read ‘What Is Secrets Management on Kubernetes?’ (part 1) ## Introduction [OpenBao](https://openbao.org/) is an open-source secrets manager, a fork of HashiCorp Vault hosted by the Linux Foundation. This tutorial installs it on a Kubernetes cluster in **dev mode** — a single in-memory server that starts already unsealed, which is perfect for learning. Dev mode keeps nothing on disk and uses a fixed root token, so use it only for tutorials and experiments, never in production. ## Step 1 — Create a local cluster (optional) If you already have a cluster, skip this. For a throwaway local cluster, [kind](https://kind.sigs.k8s.io/) works well: ```sh kind create cluster --name secrets-lab ``` ## Step 2 — Add the OpenBao Helm repository ```sh helm repo add openbao https://openbao.github.io/openbao-helm helm repo update ``` ## Step 3 — Install OpenBao in dev mode ```sh helm install openbao openbao/openbao \ --set "server.dev.enabled=true" \ --namespace openbao --create-namespace ``` ## Step 4 — Verify it is running The chart deploys an OpenBao server plus an agent injector. Wait for the server pod: ```sh kubectl get pods -l app.kubernetes.io/name=openbao -n openbao ``` ``` NAME READY STATUS RESTARTS AGE openbao-0 1/1 Running 0 20s ``` Check the server’s state with the `bao` CLI inside the pod. In dev mode the server is already unsealed and the root token is `root`: ```sh kubectl exec -n openbao openbao-0 -- sh -c \ 'BAO_ADDR=http://127.0.0.1:8200 BAO_TOKEN=root bao status' ``` ``` Sealed false Storage Type inmem Version 2.5.4 ``` `Sealed: false` means the server is ready to use. (A production OpenBao starts sealed and must be unsealed with key shares — dev mode skips that.) ## Clean up To remove OpenBao: ```sh helm uninstall openbao -n openbao ``` To tear down the whole local cluster: ```sh kind delete cluster --name secrets-lab ``` ## What’s next OpenBao is running but empty. Next you will store and read your first secrets with the key/value engine. > Next in this series: [Storing and Reading Secrets with OpenBao](/learn/security/storing-reading-secrets-openbao/). ## Summary - OpenBao installs on Kubernetes through its Helm chart; `server.dev.enabled=true` runs a single in-memory server for learning. - Dev mode starts unsealed with a fixed root token (`root`); production runs sealed and stores data on a real backend. - The `bao` CLI inside the `openbao-0` pod reports server state; `Sealed: false` means it is ready. #### Resources - [OpenBao Helm Chart](https://openbao.org/docs/platform/k8s/helm/run/) - [OpenBao Documentation](https://openbao.org/docs/) - [kind (Kubernetes in Docker)](https://kind.sigs.k8s.io/) #### On This Page - [Introduction](#introduction) - [Step 1 — Create a local cluster (optional)](#step-1--create-a-local-cluster-optional) - [Step 2 — Add the OpenBao Helm repository](#step-2--add-the-openbao-helm-repository) - [Step 3 — Install OpenBao in dev mode](#step-3--install-openbao-in-dev-mode) - [Step 4 — Verify it is running](#step-4--verify-it-is-running) - [Clean up](#clean-up) - [What’s next](#whats-next) - [Summary](#summary) --- ## Storing and Reading Secrets with OpenBao - **URL:** https://www.kubermatic.com/learn/security/storing-reading-secrets-openbao/ - **Date:** 2026-06-17 [Learn](/learn/) / [Security](/learn/security/) / Storing and Reading Secrets with OpenBao security # Storing and Reading Secrets with OpenBao ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Jun 17, 2026 2 min read Beginner [security](/learn/?tag=security) [secrets-management](/learn/?tag=secrets-management) [openbao](/learn/?tag=openbao) #### Prerequisites - Completed ‘Installing OpenBao on Kubernetes’ (part 2) — OpenBao is running in dev mode - kubectl installed and configured ## Introduction OpenBao is running, but empty. This tutorial puts secrets into it and reads them back using the key/value (KV) engine and the `bao` command-line tool. ## Step 1 — Open a shell in the OpenBao pod The `bao` CLI ships inside the server image. Exec into the pod and point the CLI at the local server. In dev mode the root token is `root`: ```sh kubectl exec -it -n openbao openbao-0 -- sh ``` Inside the pod: ```sh export BAO_ADDR=http://127.0.0.1:8200 export BAO_TOKEN=root ``` ## Step 2 — Find the key/value engine Dev mode mounts a KV version 2 engine at `secret/` for you. List the enabled engines to confirm: ```sh bao secrets list ``` ``` Path Type Description ---- ---- ----------- secret/ kv key/value secret storage ``` The `secret/` path is where your key/value secrets live. ## Step 3 — Store a secret A secret is a set of key/value pairs at a path. Store an app’s config under `secret/myapp/config`: ```sh bao kv put secret/myapp/config api_key=s3cr3t-123 db_password=hunter2 ``` ``` ====== Secret Path ====== secret/data/myapp/config ======= Metadata ======= Key Value --- ----- created_time 2026-06-17T... version 1 ``` `version 1` is the first revision of this secret. The KV v2 engine keeps a history, so each later write creates a new version and preserves the previous one. ## Step 4 — Read it back ```sh bao kv get secret/myapp/config ``` ``` ======= Data ======= Key Value --- ----- api_key s3cr3t-123 db_password hunter2 ``` To read a single field, use the `-field` flag — useful in scripts: ```sh bao kv get -field=api_key secret/myapp/config ``` ``` s3cr3t-123 ``` Type `exit` to leave the pod shell. ## A note on paths and access Paths like `secret/myapp/config` are how you organize secrets per app or team. In production you pair them with **policies** that grant a given identity read access to only the paths it needs, and OpenBao records every read in its audit log. Dev mode skips policies for simplicity; you read and write everything as the root token. ## What’s next Your secret lives in OpenBao. The final step is delivering it to a workload as a normal Kubernetes `Secret`, without copying the value into a manifest. That is the job of the External Secrets Operator. > Next in this series: [Syncing Secrets into Kubernetes with the External Secrets Operator](/learn/security/syncing-secrets-external-secrets-operator/). ## Summary - Secrets in OpenBao are key/value pairs stored at a path, such as `secret/myapp/config`. - `bao kv put` writes a secret and `bao kv get` reads it; `-field` returns a single value for scripts. - The KV v2 engine versions every write, keeping a history you can roll back to. - Production access is governed by per-path policies and recorded in an audit log. #### Resources - [OpenBao KV Secrets Engine](https://openbao.org/docs/secrets/kv/kv-v2/) - [OpenBao CLI](https://openbao.org/docs/commands/) #### On This Page - [Introduction](#introduction) - [Step 1 — Open a shell in the OpenBao pod](#step-1--open-a-shell-in-the-openbao-pod) - [Step 2 — Find the key/value engine](#step-2--find-the-keyvalue-engine) - [Step 3 — Store a secret](#step-3--store-a-secret) - [Step 4 — Read it back](#step-4--read-it-back) - [A note on paths and access](#a-note-on-paths-and-access) - [What’s next](#whats-next) - [Summary](#summary) --- ## Syncing Secrets into Kubernetes with the External Secrets Operator - **URL:** https://www.kubermatic.com/learn/security/syncing-secrets-external-secrets-operator/ - **Date:** 2026-06-17 [Learn](/learn/) / [Security](/learn/security/) / Syncing Secrets into Kubernetes with the External Secrets Operator security # Syncing Secrets into Kubernetes with the External Secrets Operator ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Jun 17, 2026 3 min read Intermediate [security](/learn/?tag=security) [secrets-management](/learn/?tag=secrets-management) [openbao](/learn/?tag=openbao) [external-secrets](/learn/?tag=external-secrets) #### Prerequisites - Completed ‘Storing and Reading Secrets with OpenBao’ (part 3) — OpenBao holds a secret at secret/myapp/config - kubectl and Helm 3 installed ## Introduction Your secret lives in OpenBao. Now you will deliver it to the cluster as an ordinary Kubernetes `Secret`, kept in sync by the [External Secrets Operator](https://external-secrets.io/) (ESO). Your manifests reference a path in OpenBao; the secret value never appears in them. ESO works through two resources: a **SecretStore** that says how to reach a backend, and an **ExternalSecret** that says which values to pull and what Kubernetes `Secret` to write. ## Step 1 — Install the External Secrets Operator ```sh helm repo add external-secrets https://charts.external-secrets.io helm repo update helm install external-secrets external-secrets/external-secrets \ -n external-secrets-system --create-namespace --wait ``` Confirm the operator is running: ```sh kubectl get pods -n external-secrets-system ``` ``` NAME READY STATUS RESTARTS AGE external-secrets-8977b889d-vt4sq 1/1 Running 0 80s external-secrets-cert-controller-5d4dc587db-pkckx 1/1 Running 0 80s external-secrets-webhook-85d855b54-4w9hq 1/1 Running 0 80s ``` ## Step 2 — Give ESO a token and a SecretStore ESO authenticates to OpenBao with a token. OpenBao is Vault-compatible, so you use ESO’s `vault` provider. Create a namespace, a Kubernetes `Secret` holding the OpenBao token (`root` in dev mode, base64-encoded as `cm9vdA==`), and a `SecretStore` pointing at the OpenBao service: ```sh kubectl create namespace demo-app kubectl apply -f- <<'EOF' apiVersion: v1 kind: Secret metadata: name: openbao-token namespace: demo-app data: token: cm9vdA== # base64("root") --- apiVersion: external-secrets.io/v1 kind: SecretStore metadata: name: openbao-backend namespace: demo-app spec: provider: vault: server: "http://openbao.openbao.svc:8200" path: "secret" version: "v2" auth: tokenSecretRef: name: "openbao-token" key: "token" EOF ``` In production you would give ESO a scoped token from a dedicated policy, with read access to only the paths it needs. ## Step 3 — Create an ExternalSecret The `ExternalSecret` names the source path and the keys to pull, and the target `Secret` to create: ```sh kubectl apply -f- <<'EOF' apiVersion: external-secrets.io/v1 kind: ExternalSecret metadata: name: myapp-config namespace: demo-app spec: refreshInterval: "15s" secretStoreRef: name: openbao-backend kind: SecretStore target: name: myapp-config data: - secretKey: api_key remoteRef: key: myapp/config property: api_key - secretKey: db_password remoteRef: key: myapp/config property: db_password EOF ``` ## Step 4 — Verify the synced Secret Check that the `ExternalSecret` synced: ```sh kubectl -n demo-app get externalsecret myapp-config ``` ``` NAME STORE REFRESH INTERVAL STATUS READY myapp-config openbao-backend 15s SecretSynced True ``` ESO created a native Kubernetes `Secret` with the values from OpenBao: ```sh kubectl -n demo-app get secret myapp-config -o jsonpath='{.data.api_key}' | base64 -d ``` ``` s3cr3t-123 ``` The value matches what you stored in OpenBao, and it never appeared in a manifest. ## Step 5 — Use it in a workload `myapp-config` is an ordinary `Secret`, so a Pod consumes it the usual way: ```yaml envFrom: - secretRef: name: myapp-config ``` When you rotate the value in OpenBao, ESO refreshes the `Secret` on its `refreshInterval`, and your workload picks up the new value on its next restart. ## Clean up ```sh kubectl delete namespace demo-app helm uninstall external-secrets -n external-secrets-system ``` ## What’s next You now have the open-source foundation: OpenBao storing secrets and ESO syncing them into Kubernetes. From here you can add per-path policies, dynamic secrets, and audit logging — and run the whole thing as a managed, multi-tenant platform with Kubermatic SecureGuard. ## Summary - The External Secrets Operator syncs secrets from a backend into native Kubernetes `Secret` objects. - A `SecretStore` defines how to reach OpenBao (the Vault-compatible provider, a token, the KV path and version). - An `ExternalSecret` names the source path and keys and the target `Secret` to write. - Workloads consume the result as a normal `Secret`; rotation in OpenBao flows through on the refresh interval. #### Resources - [External Secrets Operator](https://external-secrets.io/) - [ESO HashiCorp Vault / OpenBao Provider](https://external-secrets.io/latest/provider/hashicorp-vault/) #### On This Page - [Introduction](#introduction) - [Step 1 — Install the External Secrets Operator](#step-1--install-the-external-secrets-operator) - [Step 2 — Give ESO a token and a SecretStore](#step-2--give-eso-a-token-and-a-secretstore) - [Step 3 — Create an ExternalSecret](#step-3--create-an-externalsecret) - [Step 4 — Verify the synced Secret](#step-4--verify-the-synced-secret) - [Step 5 — Use it in a workload](#step-5--use-it-in-a-workload) - [Clean up](#clean-up) - [What’s next](#whats-next) - [Summary](#summary) --- ## What Is Secrets Management on Kubernetes? - **URL:** https://www.kubermatic.com/learn/security/what-is-secrets-management/ - **Date:** 2026-06-17 [Learn](/learn/) / [Security](/learn/security/) / What Is Secrets Management on Kubernetes? security # What Is Secrets Management on Kubernetes? ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Jun 17, 2026 3 min read Beginner [getting-started](/learn/?tag=getting-started) [security](/learn/?tag=security) [secrets-management](/learn/?tag=secrets-management) #### Prerequisites - Basic understanding of Kubernetes concepts (Pods, Secrets, etcd) - Familiarity with environment variables and configuration ## Introduction Every application needs secrets: database passwords, API keys, TLS certificates, tokens. On Kubernetes the quickest path is to drop them into environment variables, a ConfigMap, or a `Secret` checked into Git. Each of those leaks credentials somewhere they shouldn’t be. This tutorial explains the problem and the pattern that solves it: a dedicated secrets manager holding the real secrets, and an operator that syncs them into the Kubernetes Secrets your apps already know how to read. ## Why Kubernetes Secrets alone fall short A Kubernetes `Secret` is a useful primitive, with real limits: - **It is only base64-encoded.** Secret values sit in etcd as base64, which anyone with cluster or etcd access can decode unless you separately enable encryption at rest. - **It lives in Git if you GitOps it.** Committing a `Secret` manifest puts the credential in version history for anyone with repo access. - **It does not rotate.** A `Secret` holds a static value. Rotating the underlying credential means editing and re-applying the manifest by hand. - **There is no audit trail.** Kubernetes does not record who read which secret value. For a single throwaway app these are tolerable. Across a platform with many teams and real credentials, they become a liability. ## A secrets manager plus a sync operator The widely used answer pairs two open-source tools. [OpenBao](https://openbao.org/) is the secrets manager. A fork of HashiCorp Vault hosted by the Linux Foundation, it stores the real secrets in one encrypted, access-controlled, audited place, with a key/value store, dynamic secrets, fine-grained policies, and an audit log. The [External Secrets Operator](https://external-secrets.io/) (ESO) is the sync layer. It reads from a backend like OpenBao and creates ordinary Kubernetes `Secret` objects for your workloads. Your application keeps reading a normal `Secret`, and the operator keeps it in step with the source. The flow looks like this: ``` OpenBao (source of truth) -> External Secrets Operator -> Kubernetes Secret -> your Pod ``` ## What you get - **Credentials stay out of Git and manifests.** Your repo holds an `ExternalSecret` that references a path, never the secret value. - **One audited, access-controlled source.** Policies decide who and what can read each secret, and reads are logged. - **Rotation propagates.** Update the value in OpenBao and ESO re-syncs the Kubernetes `Secret` on its refresh interval. - **Apps stay unchanged.** Workloads consume a standard `Secret`, so nothing in the application has to know about OpenBao. ## What’s next The rest of this series is hands-on. You will install OpenBao on a Kubernetes cluster, store and read secrets with it, and then wire up the External Secrets Operator to sync those secrets into your workloads. > Next in this series: [Installing OpenBao on Kubernetes](/learn/security/installing-openbao-kubernetes/). ## Summary - A Kubernetes `Secret` is base64-encoded, static, un-audited, and ends up in Git when you GitOps it. - A secrets manager (OpenBao) keeps the real secrets in one encrypted, policy-controlled, audited place. - The External Secrets Operator syncs secrets from OpenBao into ordinary Kubernetes `Secret` objects. - Your manifests reference a path, your apps read a normal `Secret`, and rotation flows through automatically. #### Resources - [OpenBao](https://openbao.org/) - [External Secrets Operator](https://external-secrets.io/) #### On This Page - [Introduction](#introduction) - [Why Kubernetes Secrets alone fall short](#why-kubernetes-secrets-alone-fall-short) - [A secrets manager plus a sync operator](#a-secrets-manager-plus-a-sync-operator) - [What you get](#what-you-get) - [What’s next](#whats-next) - [Summary](#summary) --- ## What Is an Agent Gateway, and Why Does Agentic AI Need One? - **URL:** https://www.kubermatic.com/blog/what-is-an-agent-gateway/ - **Date:** 2026-06-17 - **Description:** What an agent gateway is, why agentic AI needs one, and the main use cases. A practitioner's explainer on the data plane for MCP, agent-to-agent, and LLM traffic. - **Categories:** Kubernetes - **Authors:** Abubakar Siddiq Ango If you've shipped anything with AI agents recently, you've probably wired an agent to a tool with the **Model Context Protocol (MCP)**, called more than one model provider, and maybe had two agents talk to each other. Each of those connections is a piece of network traffic, and right now most teams manage each one by hand, in application code. An **agent gateway** gives all of that traffic a single place to be managed. ## What is an agent gateway? An agent gateway is a **data plane for agent traffic**. It's a single proxy that sits between your agents and everything they talk to, and it applies routing, security, and observability consistently across all of it. A traditional API gateway handles north-south HTTP traffic: authentication, rate limiting, routing to backends. An agent gateway does the same job for the traffic patterns agentic systems generate: - **MCP:** the calls an agent makes to discover and invoke tools. - **Agent-to-Agent (A2A):** messages between agents, often across frameworks (LangChain, CrewAI, ADK). - **LLM inference:** requests to model providers (OpenAI, Anthropic, Bedrock, Gemini) or to self-hosted models on your own GPUs (vLLM, TGI, Triton). - **Regular service traffic:** the plain HTTP, gRPC, and REST APIs your agents still call. One gateway handles those concerns once, so no agent has to reimplement auth, retries, logging, and policy for every protocol. [agentgateway](https://agentgateway.dev/), recently donated to the Linux Foundation's [Agentic AI Foundation](https://aaif.io/), describes itself as "one high-performance gateway for service, LLM, and MCP traffic." ## Why does agentic AI need one? Agents need a gateway for the same reasons microservices did, plus a few sharper ones. Four stand out: **1. The same problems microservices had.** Agentic systems need authentication, authorization, rate limiting, retries, and observability, exactly like microservices did. Without a gateway, every agent and every tool integration solves them again, inconsistently. One agent logs every tool call; the next logs nothing. **2. Agents carry real authority.** When an agent invokes a tool, it's taking an action: writing to a database, sending an email, moving money. The blast radius of a bad call is larger than a normal API request, which is why you want a single enforcement point for which agent may call which tool, with which arguments. **3. Models and tools change constantly.** Teams switch model providers for cost or quality, add new MCP tools weekly, and run some inference locally and some in the cloud. A gateway lets you route, fail over, and budget across providers without rewriting the agent. **4. Governance depends on visibility.** Compliance, cost control, and debugging all depend on observability. A gateway that emits metrics, traces, and audit logs for every tool call and inference request turns "what did the agent do?" from a guess into a query. The agent gateway is becoming the **control point for agentic systems**, the layer where governance, security, and observability are enforced. ## Main use cases **MCP gateway.** Expose a curated set of MCP tools through one endpoint with discovery, RBAC, and audit logging. Each agent works from one governed catalog, with no direct, ungoverned connections to the underlying systems. **LLM gateway.** Put one endpoint in front of multiple model providers, with token budgets, semantic caching, and failover. A provider outage or a price change is handled in config, with no agent code to rewrite. **Inference routing.** Route inference across self-hosted model servers (vLLM, TGI, Triton) with latency- and cost-aware policies, so expensive GPU capacity is used deliberately. **Agent-to-agent communication.** Bridge agents built in different frameworks over A2A, with the same auth and observability you apply everywhere else. **Unified policy and observability.** Apply one set of security controls (mTLS, authn/authz, policy-as-code) and one observability pipeline (OpenTelemetry) across agent and traditional traffic, so the AI parts run through the same stack as everything else. ## Where Kubernetes fits Most of these gateways are designed to run on Kubernetes. Take agentgateway: it deploys via Helm and the Gateway API, and it's Envoy-compatible. The agentic data plane behaves like the rest of your platform. You deploy it declaratively, scale it horizontally, govern it with policy-as-code, and connect it to the service networking you already run. Running it on the same Kubernetes substrate as your other infrastructure means one operational model, one security posture, and one place to reason about where your agents' most sensitive traffic flows. If you're already running platforms on Kubernetes, the agentic data plane is just another workload on infrastructure you already operate, ideally one you control. ## Takeaways - An **agent gateway** is a data plane for agent traffic (MCP, A2A, LLM inference, and regular services) with consistent routing, security, and observability. - Agentic systems need it for the same reasons microservices needed an API gateway: shared cross-cutting concerns, plus the higher stakes of agents that *act*. - The main use cases are governed MCP tool access, multi-provider LLM routing, GPU-aware inference routing, A2A bridging, and unified policy and observability. - Running it on Kubernetes keeps the agentic control point on infrastructure you operate and control. If you already run Kubermatic's [KubeLB](https://docs.kubermatic.com/kubelb/v1.4/tutorials/aigateway/), you have this today. Its AI & MCP Gateway uses agentgateway as the data plane and federates MCP servers behind a single endpoint via the `AgentgatewayBackend` CRD. And if you want to go hands-on from the ground up, the new **AI Infrastructure** track in [Kubermatic Learn](/learn/) walks through deploying and configuring an agent gateway on Kubernetes step by step. --- ## Agent-to-Agent Communication - **URL:** https://www.kubermatic.com/learn/ai-infrastructure/agent-to-agent-communication/ - **Date:** 2026-06-17 [Learn](/learn/) / [Ai-Infrastructure](/learn/ai-infrastructure/) / Agent-to-Agent Communication ai-infrastructure # Agent-to-Agent Communication ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Jun 16, 2026 3 min read Intermediate [ai-infrastructure](/learn/?tag=ai-infrastructure) [agentic-ai](/learn/?tag=agentic-ai) [a2a](/learn/?tag=a2a) #### Prerequisites - Completed ‘Installing an Agent Gateway on Kubernetes’ (part 2) — agentgateway and the `agentgateway-proxy` Gateway are running - kubectl installed and configured ## Introduction Agents rarely work alone. A supervisor hands work to a researcher; a coder calls a reviewer. The [A2A protocol](https://a2a-protocol.org/) standardizes those exchanges, and the agent gateway carries them — so calls between agents get the same routing, security, and observability as the rest of your traffic. This tutorial puts a sample A2A agent behind the gateway, fetches its agent card, and sends it a task. ## Step 1 — Deploy a sample A2A agent This Echo Agent returns whatever message it receives. The Service marks itself as A2A with `appProtocol: kgateway.dev/a2a`, which tells the gateway how to handle the backend: ```sh kubectl apply -f- <<'EOF' apiVersion: apps/v1 kind: Deployment metadata: name: a2a-agent labels: { app: a2a-agent } spec: selector: matchLabels: { app: a2a-agent } template: metadata: labels: { app: a2a-agent } spec: containers: - name: a2a-agent image: gcr.io/solo-public/docs/test-a2a-agent:latest ports: - containerPort: 9090 --- apiVersion: v1 kind: Service metadata: name: a2a-agent spec: selector: { app: a2a-agent } type: ClusterIP ports: - protocol: TCP port: 9090 targetPort: 9090 appProtocol: kgateway.dev/a2a EOF ``` ## Step 2 — Route to the agent Because the Service is tagged as A2A, you route to it directly: ```sh kubectl apply -f- <<'EOF' apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: a2a spec: parentRefs: - name: agentgateway-proxy namespace: agentgateway-system rules: - backendRefs: - name: a2a-agent port: 9090 EOF ``` ## Step 3 — Discover the agent Port-forward the proxy: ```sh kubectl port-forward deployment/agentgateway-proxy -n agentgateway-system 8080:80 ``` A2A agents publish an agent card describing who they are and what they can do. Fetch it through the gateway: ```sh curl -s http://localhost:8080/.well-known/agent.json ``` ```json { "name": "Echo Agent", "description": "This agent echos the input given", "version": "0.1.0", "capabilities": { "streaming": true }, "defaultInputModes": ["text"], "defaultOutputModes": ["text"] } ``` ## Step 4 — Send the agent a task Send an A2A `tasks/send` request, the same call one agent would make to another: ```sh curl -s -X POST http://localhost:8080/ -H "Content-Type: application/json" -d '{ "jsonrpc": "2.0", "id": "1", "method": "tasks/send", "params": { "id": "1", "message": { "role": "user", "parts": [ { "type": "text", "text": "hello gateway!" } ] } } }' ``` ```json { "jsonrpc": "2.0", "id": "1", "result": { "status": { "state": "completed", "message": { "role": "agent", "parts": [ { "type": "text", "text": "on_send_task received: hello gateway!" } ] } } } } ``` The task ran on the agent and came back `completed`, routed through agentgateway. A calling agent reaches every agent through this one endpoint, so discovery and security live at the gateway and apply to all of them. ## Clean up ```sh kubectl delete httproute a2a kubectl delete deployment,service a2a-agent ``` ## What’s next You have tools, models, and agents all flowing through the gateway. The final tutorial secures that traffic: API-key and JWT authentication, CEL-based access rules, and OpenTelemetry traces. > Next in this series: [Securing Agent Traffic with Policy and Observability](/learn/ai-infrastructure/securing-agent-traffic/). ## Summary - An A2A backend is an ordinary Service tagged with `appProtocol: kgateway.dev/a2a`; an `HTTPRoute` attaches it to the Gateway. - Agents publish an agent card at `/.well-known/agent.json`, served through the gateway. - A `tasks/send` call runs work on the agent and returns its result, carried by agentgateway. - One endpoint fronts every agent, so discovery, auth, and observability attach once. #### Resources - [agentgateway A2A Docs](https://agentgateway.dev/docs/kubernetes/latest/agent/a2a.md) - [A2A Protocol](https://a2a-protocol.org/) #### On This Page - [Introduction](#introduction) - [Step 1 — Deploy a sample A2A agent](#step-1--deploy-a-sample-a2a-agent) - [Step 2 — Route to the agent](#step-2--route-to-the-agent) - [Step 3 — Discover the agent](#step-3--discover-the-agent) - [Step 4 — Send the agent a task](#step-4--send-the-agent-a-task) - [Clean up](#clean-up) - [What’s next](#whats-next) - [Summary](#summary) --- ## Installing an Agent Gateway on Kubernetes - **URL:** https://www.kubermatic.com/learn/ai-infrastructure/installing-agent-gateway-kubernetes/ - **Date:** 2026-06-17 [Learn](/learn/) / [Ai-Infrastructure](/learn/ai-infrastructure/) / Installing an Agent Gateway on Kubernetes ai-infrastructure # Installing an Agent Gateway on Kubernetes ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Jun 16, 2026 4 min read Beginner [getting-started](/learn/?tag=getting-started) [ai-infrastructure](/learn/?tag=ai-infrastructure) [agentic-ai](/learn/?tag=agentic-ai) #### Prerequisites - A Kubernetes cluster (this tutorial uses a local kind cluster) - kubectl installed and configured - Helm 3 installed - Read ‘What Is an Agent Gateway?’ (part 1 of this series) ## Introduction In part 1 we covered what an agent gateway is and why agentic systems need one. This tutorial gets one running. You will install [agentgateway](https://agentgateway.dev/) — the open-source (Apache-2.0) data plane hosted by the Linux Foundation’s Agentic AI Foundation — onto a Kubernetes cluster, create a Gateway, and send your first request through it. Everything here runs on open-source components, so you can follow along on a free local cluster. Versions used in this tutorial: Gateway API `v1.5.0`, agentgateway `v1.2.1`. ## Step 1 — Create a local cluster (optional) If you already have a cluster, skip this. For a throwaway local cluster, [kind](https://kind.sigs.k8s.io/) is the quickest option: ```sh kind create cluster --name agw-lab ``` Confirm the node is ready: ```sh kubectl get nodes ``` ``` NAME STATUS ROLES AGE VERSION agw-lab-control-plane Ready control-plane 60s v1.36.1 ``` ## Step 2 — Install the Gateway API CRDs agentgateway is configured through the Kubernetes [Gateway API](https://gateway-api.sigs.k8s.io/), so its custom resources go in first: ```sh kubectl apply --server-side --force-conflicts \ -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.5.0/standard-install.yaml ``` ## Step 3 — Install the agentgateway CRDs agentgateway ships as two Helm charts: the CRDs and the control plane. Install the CRDs first: ```sh helm upgrade -i agentgateway-crds oci://cr.agentgateway.dev/charts/agentgateway-crds \ --create-namespace --namespace agentgateway-system \ --version v1.2.1 \ --set controller.image.pullPolicy=Always ``` ## Step 4 — Install the agentgateway control plane ```sh helm upgrade -i agentgateway oci://cr.agentgateway.dev/charts/agentgateway \ --namespace agentgateway-system \ --version v1.2.1 \ --set controller.image.pullPolicy=Always \ --set controller.extraEnv.KGW_ENABLE_GATEWAY_API_EXPERIMENTAL_FEATURES=true \ --wait ``` The control plane watches Gateway API and agentgateway resources and turns them into running proxies. ## Step 5 — Verify the install Check the control-plane pod: ```sh kubectl get pods -n agentgateway-system ``` ``` NAME READY STATUS RESTARTS AGE agentgateway-68c7bd47d-kh528 1/1 Running 0 20s ``` Confirm the GatewayClass was registered and accepted: ```sh kubectl get gatewayclass agentgateway ``` ``` NAME CONTROLLER ACCEPTED AGE agentgateway agentgateway.dev/agentgateway True 30s ``` `ACCEPTED: True` means the control plane is ready to manage Gateways of this class. ## Step 6 — Create a Gateway The control plane is running, but no proxy exists yet. Create a `Gateway` and the control plane will provision one for you: ```yaml apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: agentgateway-proxy namespace: agentgateway-system spec: gatewayClassName: agentgateway listeners: - name: http protocol: HTTP port: 80 allowedRoutes: namespaces: from: All ``` Apply it (save the file as `gateway.yaml` or pipe it with `kubectl apply -f -`), then check its status: ```sh kubectl get gateway agentgateway-proxy -n agentgateway-system ``` ``` NAME CLASS ADDRESS PROGRAMMED AGE agentgateway-proxy agentgateway True 10s ``` `PROGRAMMED: True` means the proxy is deployed and ready for routes. ## Step 7 — Route a request to a backend Deploy a sample HTTP backend (httpbin): ```sh kubectl apply -f https://raw.githubusercontent.com/kgateway-dev/kgateway/refs/heads/main/examples/httpbin.yaml ``` Attach an `HTTPRoute` that sends traffic for `www.example.com` to it: ```yaml apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: httpbin namespace: httpbin spec: parentRefs: - name: agentgateway-proxy namespace: agentgateway-system hostnames: - "www.example.com" rules: - backendRefs: - name: httpbin port: 8000 ``` ## Step 8 — Send a request through the gateway Port-forward the proxy in one terminal: ```sh kubectl port-forward deployment/agentgateway-proxy -n agentgateway-system 8080:80 ``` In another terminal, call the route: ```sh curl -i localhost:8080/headers -H "host: www.example.com" ``` ``` HTTP/1.1 200 OK content-type: application/json; encoding=utf-8 content-length: 148 { "headers": { "Host": [ "www.example.com" ], "User-Agent": [ "curl/8.7.1" ] } } ``` A `200` with the headers echoed back confirms the request travelled through agentgateway to the backend. You now have a working agent gateway. ## Clean up Remove the demo route when you are done, so it does not collide with later tutorials: ```sh kubectl delete httproute httpbin -n httpbin ``` To tear down the whole local cluster: ```sh kind delete cluster --name agw-lab ``` ## What’s next You have a gateway routing plain HTTP. The next tutorial puts it to work on agent traffic: exposing a Model Context Protocol (MCP) tool through the gateway, with discovery and an audit trail. > Next in this series: [Your First MCP Gateway](/learn/ai-infrastructure/your-first-mcp-gateway/). ## Summary - agentgateway installs as two Helm charts (CRDs + control plane) on top of the Kubernetes Gateway API. - The control plane registers an `agentgateway` GatewayClass and turns each `Gateway` you create into a running proxy. - An `HTTPRoute` attaches a backend to the Gateway, and a request through the proxy returns `200`. - Every component here is open source, so the setup runs on a free local kind cluster. #### Resources - [agentgateway Install Docs](https://agentgateway.dev/docs/kubernetes/latest/quickstart/install/) - [Kubernetes Gateway API](https://gateway-api.sigs.k8s.io/) - [kind (Kubernetes in Docker)](https://kind.sigs.k8s.io/) #### On This Page - [Introduction](#introduction) - [Step 1 — Create a local cluster (optional)](#step-1--create-a-local-cluster-optional) - [Step 2 — Install the Gateway API CRDs](#step-2--install-the-gateway-api-crds) - [Step 3 — Install the agentgateway CRDs](#step-3--install-the-agentgateway-crds) - [Step 4 — Install the agentgateway control plane](#step-4--install-the-agentgateway-control-plane) - [Step 5 — Verify the install](#step-5--verify-the-install) - [Step 6 — Create a Gateway](#step-6--create-a-gateway) - [Step 7 — Route a request to a backend](#step-7--route-a-request-to-a-backend) - [Step 8 — Send a request through the gateway](#step-8--send-a-request-through-the-gateway) - [Clean up](#clean-up) - [What’s next](#whats-next) - [Summary](#summary) --- ## Routing LLM Traffic Across Providers - **URL:** https://www.kubermatic.com/learn/ai-infrastructure/routing-llm-traffic/ - **Date:** 2026-06-17 [Learn](/learn/) / [Ai-Infrastructure](/learn/ai-infrastructure/) / Routing LLM Traffic Across Providers ai-infrastructure # Routing LLM Traffic Across Providers ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Jun 16, 2026 4 min read Intermediate [ai-infrastructure](/learn/?tag=ai-infrastructure) [agentic-ai](/learn/?tag=agentic-ai) [llm](/learn/?tag=llm) #### Prerequisites - Completed ‘Installing an Agent Gateway on Kubernetes’ (part 2) — agentgateway and the `agentgateway-proxy` Gateway are running - An OpenAI-compatible model endpoint you can reach from the cluster. This tutorial uses a local llama.cpp server, but Ollama, vLLM, or a hosted provider work the same way. - kubectl installed and configured ## Introduction A second job for the agent gateway is sitting in front of the models your agents call. Your application talks to one OpenAI-compatible endpoint — the gateway — and the gateway decides which provider actually serves each request. Switching or adding a provider becomes a configuration change, with no application code to touch. This tutorial routes chat completions through agentgateway to a model running on your own machine, then load-balances across two providers. Using a self-hosted model keeps the whole tutorial free of paid API calls. This walkthrough uses a local [llama.cpp](https://github.com/ggml-org/llama.cpp) server on port `8090` serving `gemma-4-12b`, reachable from the cluster at `host.docker.internal:8090`. Any OpenAI-compatible endpoint works — substitute your own host, port, and model name. ## Step 1 — Point a backend at your model An LLM backend is an `AgentgatewayBackend` with an `ai` provider. The `host` and `port` under `provider` override the default endpoint, so the gateway sends requests to your server. Self-hosted endpoints usually need no key, so the auth block is omitted: ```sh kubectl apply -f- <<'EOF' apiVersion: agentgateway.dev/v1alpha1 kind: AgentgatewayBackend metadata: name: local-llm namespace: agentgateway-system spec: ai: provider: host: host.docker.internal port: 8090 openai: model: gemma-4-12b-it-Q5_K_M.gguf EOF ``` Confirm it is accepted: ```sh kubectl get agentgatewaybackend local-llm -n agentgateway-system ``` ``` NAME ACCEPTED AGE local-llm True 4s ``` ## Step 2 — Route and test a chat completion Attach the backend to the gateway: ```sh kubectl apply -f- <<'EOF' apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: local-llm namespace: agentgateway-system spec: parentRefs: - name: agentgateway-proxy namespace: agentgateway-system rules: - backendRefs: - name: local-llm namespace: agentgateway-system group: agentgateway.dev kind: AgentgatewayBackend EOF ``` Port-forward the proxy and send a standard OpenAI chat-completions request: ```sh kubectl port-forward deployment/agentgateway-proxy -n agentgateway-system 8080:80 ``` ```sh curl -s localhost:8080/v1/chat/completions -H 'content-type: application/json' -d '{ "model": "", "messages": [{"role": "user", "content": "Reply with exactly: agentgateway works"}] }' ``` ```json { "model": "gemma-4-12b-it-Q5_K_M.gguf", "choices": [{ "message": { "role": "assistant", "content": "agentgateway works" }, "finish_reason": "stop" }], "usage": { "prompt_tokens": 23, "completion_tokens": 57, "total_tokens": 80 } } ``` Your application sent a normal OpenAI request to the gateway, and the gateway served it from the model on your machine. ## Step 3 — Load-balance across providers To spread traffic — or fail over — list several providers in one backend. agentgateway balances across the providers in a group using a power-of-two-choices algorithm. The example below uses two entries pointing at the same local server to keep things free; in production each entry is a different provider, and a hosted one adds an `auth` block referencing a Secret: ```sh kubectl apply -f- <<'EOF' apiVersion: agentgateway.dev/v1alpha1 kind: AgentgatewayBackend metadata: name: llm-pool namespace: agentgateway-system spec: ai: groups: - providers: - name: local-a host: host.docker.internal port: 8090 openai: model: gemma-4-12b-it-Q5_K_M.gguf - name: local-b host: host.docker.internal port: 8090 openai: model: gemma-4-12b-it-Q5_K_M.gguf EOF ``` Route to the pool and test it the same way: ```sh kubectl apply -f- <<'EOF' apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: llm-pool namespace: agentgateway-system spec: parentRefs: - name: agentgateway-proxy namespace: agentgateway-system rules: - backendRefs: - name: llm-pool namespace: agentgateway-system group: agentgateway.dev kind: AgentgatewayBackend EOF ``` ```sh curl -s localhost:8080/v1/chat/completions -H 'content-type: application/json' -d '{ "model": "", "messages": [{"role": "user", "content": "Reply with exactly: pool ok"}] }' ``` ```json { "model": "gemma-4-12b-it-Q5_K_M.gguf", "choices": [{ "message": { "content": "pool ok" }, "finish_reason": "stop" }], "usage": { "total_tokens": 105 } } ``` To make this a real failover, give one provider entry a different `host`/`model` (say a hosted provider with an `auth.secretRef`) and keep your self-hosted model as the other. The gateway then balances healthy providers and routes around one that is failing — and your application keeps calling the same endpoint. ## A note on adding a hosted provider A hosted provider needs a key. Create a Secret and reference it from the provider’s `policies.auth`: ```yaml # inside a provider entry - name: openai openai: model: gpt-4o policies: auth: secretRef: name: openai-secret ``` agentgateway also tracks token usage per request, which is the basis for budgets and cost reporting (see the LLM docs linked below). ## Clean up ```sh kubectl delete httproute local-llm llm-pool -n agentgateway-system kubectl delete agentgatewaybackend local-llm llm-pool -n agentgateway-system ``` ## What’s next The gateway now fronts your tools (MCP) and your models (LLM). Next, it carries traffic between agents themselves: agent-to-agent (A2A) communication with consistent security. > Next in this series: [Agent-to-Agent Communication](/learn/ai-infrastructure/agent-to-agent-communication/). ## Summary - An LLM backend is an `AgentgatewayBackend` whose `ai.provider` sets `host`, `port`, and `openai.model`; self-hosted endpoints need no auth block. - Applications send normal OpenAI chat-completions requests to the gateway, and the gateway serves them from the configured provider. - `ai.groups[].providers[]` lists several providers in one backend; the gateway load-balances across them and routes around an unhealthy one. - A hosted provider adds `policies.auth.secretRef`; the application endpoint never changes. #### Resources - [agentgateway LLM Docs](https://agentgateway.dev/docs/kubernetes/latest/llm/about.md) - [agentgateway Load Balancing](https://agentgateway.dev/docs/kubernetes/latest/llm/load-balancing.md) - [llama.cpp (OpenAI-compatible server)](https://github.com/ggml-org/llama.cpp) #### On This Page - [Introduction](#introduction) - [Step 1 — Point a backend at your model](#step-1--point-a-backend-at-your-model) - [Step 2 — Route and test a chat completion](#step-2--route-and-test-a-chat-completion) - [Step 3 — Load-balance across providers](#step-3--load-balance-across-providers) - [A note on adding a hosted provider](#a-note-on-adding-a-hosted-provider) - [Clean up](#clean-up) - [What’s next](#whats-next) - [Summary](#summary) --- ## Securing Agent Traffic with Policy and Observability - **URL:** https://www.kubermatic.com/learn/ai-infrastructure/securing-agent-traffic/ - **Date:** 2026-06-17 [Learn](/learn/) / [Ai-Infrastructure](/learn/ai-infrastructure/) / Securing Agent Traffic with Policy and Observability ai-infrastructure # Securing Agent Traffic with Policy and Observability ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Jun 16, 2026 3 min read Intermediate [ai-infrastructure](/learn/?tag=ai-infrastructure) [agentic-ai](/learn/?tag=agentic-ai) [security](/learn/?tag=security) [observability](/learn/?tag=observability) #### Prerequisites - Completed ‘Installing an Agent Gateway on Kubernetes’ (part 2) — agentgateway and the `agentgateway-proxy` Gateway are running - kubectl installed and configured ## Introduction Across this series the gateway became the one path your tools, models, and agents share. That makes it the right place to enforce who may call what, and the one place that can tell you what happened. This tutorial adds an authentication policy to the gateway and reads the logs it produces for every request. ## Step 1 — Expose a backend to protect If you still have a route from an earlier tutorial, use it. Otherwise, deploy the httpbin sample and route to it: ```sh kubectl apply -f https://raw.githubusercontent.com/kgateway-dev/kgateway/refs/heads/main/examples/httpbin.yaml kubectl apply -f- <<'EOF' apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: httpbin namespace: httpbin spec: parentRefs: - name: agentgateway-proxy namespace: agentgateway-system hostnames: ["www.example.com"] rules: - backendRefs: - name: httpbin port: 8000 EOF ``` ## Step 2 — Enforce API-key authentication Store one or more keys in a Secret: ```sh kubectl apply -f- <<'EOF' apiVersion: v1 kind: Secret metadata: name: apikey namespace: agentgateway-system labels: app: httpbin type: extauth.solo.io/apikey stringData: api-key: N2YwMDIxZTEtNGUzNS1jNzgzLTRkYjAtYjE2YzRkZGVmNjcy EOF ``` Attach an `AgentgatewayPolicy` that requires a valid key. This one targets the whole `agentgateway-proxy` Gateway, so it covers every route: ```sh kubectl apply -f- <<'EOF' apiVersion: agentgateway.dev/v1alpha1 kind: AgentgatewayPolicy metadata: name: apikey-auth namespace: agentgateway-system spec: targetRefs: - group: gateway.networking.k8s.io kind: Gateway name: agentgateway-proxy traffic: apiKeyAuthentication: mode: Strict secretRef: name: apikey EOF ``` ## Step 3 — Test the gate Port-forward the proxy: ```sh kubectl port-forward deployment/agentgateway-proxy -n agentgateway-system 8080:80 ``` A request with no key is rejected: ```sh curl -s -o /dev/null -w "HTTP %{http_code}\n" localhost:8080/headers -H "host: www.example.com" ``` ``` HTTP 401 ``` The same request with a valid `Authorization: Bearer` key passes: ```sh curl -s -o /dev/null -w "HTTP %{http_code}\n" localhost:8080/headers \ -H "host: www.example.com" \ -H "Authorization: Bearer N2YwMDIxZTEtNGUzNS1jNzgzLTRkYjAtYjE2YzRkZGVmNjcy" ``` ``` HTTP 200 ``` The gateway enforced the policy before the request reached the backend. ## Step 4 — Read the access logs agentgateway logs every request it handles. Watch them on the proxy: ```sh kubectl logs deploy/agentgateway-proxy -n agentgateway-system --tail=5 ``` ``` ... route=httpbin/httpbin http.method=GET http.host=www.example.com http.path=/headers http.status=401 protocol=http error="api key authentication failure: no API Key found" reason=APIKeyAuth duration=1ms ... route=httpbin/httpbin endpoint=10.244.0.7:8080 http.method=GET http.host=www.example.com http.path=/headers http.status=200 protocol=http duration=4ms ``` Each line records the route, method, host, path, status, protocol, and duration — and, for the rejected call, the exact reason (`APIKeyAuth`). The same logging covers MCP, LLM, and A2A traffic, with the protocol named on each line, so one stream answers “what did the agents do, and what was allowed?” For distributed traces across agents and tools, agentgateway exports OpenTelemetry; see the tracing docs linked below. ## Going further - **Finer-grained rules.** You can scope a policy to a single `HTTPRoute`, and CEL-based RBAC restricts which caller may use which tool or model. - **Other auth methods.** JWT authentication validates tokens from your identity provider. - **Tracing and metrics.** Point the gateway at an OpenTelemetry collector for end-to-end traces and Prometheus-style metrics. ## Clean up ```sh kubectl delete agentgatewaypolicy apikey-auth -n agentgateway-system kubectl delete secret apikey -n agentgateway-system kubectl delete httproute httpbin -n httpbin ``` To remove the whole lab cluster: ```sh kind delete cluster --name agw-lab ``` ## Series wrap-up You started with an empty cluster and finished with an agent gateway that routes tools (MCP), models (LLM), and agents (A2A) through one place, with authentication enforced and every request logged. The same setup runs on any Kubernetes cluster you operate, on open-source components. ## Summary - An `AgentgatewayPolicy` with `traffic.apiKeyAuthentication` enforces keys at the gateway; a `targetRef` scopes it to a Gateway or a single route. - Keys live in a Secret of type `extauth.solo.io/apikey`; clients send `Authorization: Bearer <key>`. - The gateway logs every request — route, status, protocol, duration, and the auth reason — across MCP, LLM, and A2A traffic. - CEL RBAC, JWT auth, and OpenTelemetry tracing extend this for production. #### Resources - [agentgateway API-Key Auth](https://agentgateway.dev/docs/kubernetes/latest/security/apikey.md) - [agentgateway CEL RBAC](https://agentgateway.dev/docs/kubernetes/latest/llm/rbac.md) - [agentgateway Tracing (OpenTelemetry)](https://agentgateway.dev/docs/kubernetes/latest/observability/tracing.md) #### On This Page - [Introduction](#introduction) - [Step 1 — Expose a backend to protect](#step-1--expose-a-backend-to-protect) - [Step 2 — Enforce API-key authentication](#step-2--enforce-api-key-authentication) - [Step 3 — Test the gate](#step-3--test-the-gate) - [Step 4 — Read the access logs](#step-4--read-the-access-logs) - [Going further](#going-further) - [Clean up](#clean-up) - [Series wrap-up](#series-wrap-up) - [Summary](#summary) --- ## Your First MCP Gateway - **URL:** https://www.kubermatic.com/learn/ai-infrastructure/your-first-mcp-gateway/ - **Date:** 2026-06-17 [Learn](/learn/) / [Ai-Infrastructure](/learn/ai-infrastructure/) / Your First MCP Gateway ai-infrastructure # Your First MCP Gateway ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Jun 16, 2026 4 min read Beginner [getting-started](/learn/?tag=getting-started) [ai-infrastructure](/learn/?tag=ai-infrastructure) [agentic-ai](/learn/?tag=agentic-ai) [mcp](/learn/?tag=mcp) #### Prerequisites - Completed ‘Installing an Agent Gateway on Kubernetes’ (part 2) — you have agentgateway and the `agentgateway-proxy` Gateway running - kubectl installed and configured - Node.js available, to run the MCP Inspector with npx ## Introduction An agent gateway earns its keep on agent traffic, and the most common kind is the [Model Context Protocol (MCP)](https://modelcontextprotocol.io/) — the calls an agent makes to discover and invoke tools. This tutorial puts an MCP server behind the gateway you installed in part 2, then discovers and calls its tools through one endpoint. You will deploy a sample MCP server, expose it with an `AgentgatewayBackend`, attach a route, and call a tool through the proxy. ## Step 1 — Deploy a sample MCP server This MCP server exposes a single `fetch` tool that retrieves a web page. Note the `appProtocol: agentgateway.dev/mcp` on the Service — that tells agentgateway the backend speaks MCP. ```sh kubectl apply -f- <<'EOF' apiVersion: apps/v1 kind: Deployment metadata: name: mcp-website-fetcher spec: selector: matchLabels: app: mcp-website-fetcher template: metadata: labels: app: mcp-website-fetcher spec: containers: - name: mcp-website-fetcher image: ghcr.io/peterj/mcp-website-fetcher:main imagePullPolicy: Always --- apiVersion: v1 kind: Service metadata: name: mcp-website-fetcher labels: app: mcp-website-fetcher spec: selector: app: mcp-website-fetcher ports: - port: 80 targetPort: 8000 appProtocol: agentgateway.dev/mcp EOF ``` ## Step 2 — Expose it with an AgentgatewayBackend The `AgentgatewayBackend` resource is how you register an agent backend. For MCP, you list one or more targets; here a single static target points at the Service: ```sh kubectl apply -f- <<'EOF' apiVersion: agentgateway.dev/v1alpha1 kind: AgentgatewayBackend metadata: name: mcp-backend spec: mcp: targets: - name: mcp-target static: backendRef: name: mcp-website-fetcher port: 80 protocol: SSE EOF ``` Confirm it is accepted: ```sh kubectl get agentgatewaybackend mcp-backend ``` ``` NAME ACCEPTED AGE mcp-backend True 4s ``` ## Step 3 — Attach a route Route requests under `/mcp` on the gateway to the backend. Because the backend is an `AgentgatewayBackend`, the `backendRef` names its `group` and `kind`: ```sh kubectl apply -f- <<'EOF' apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: mcp spec: parentRefs: - name: agentgateway-proxy namespace: agentgateway-system rules: - matches: - path: type: PathPrefix value: /mcp backendRefs: - name: mcp-backend group: agentgateway.dev kind: AgentgatewayBackend EOF ``` ## Step 4 — Connect to the MCP endpoint Port-forward the proxy: ```sh kubectl port-forward deployment/agentgateway-proxy -n agentgateway-system 8080:80 ``` The gateway now serves MCP over Streamable HTTP at `http://localhost:8080/mcp`. A raw `initialize` call confirms the server is reachable through the proxy: ```sh curl -s -X POST localhost:8080/mcp \ -H 'Content-Type: application/json' \ -H 'Accept: application/json, text/event-stream' \ -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"curl","version":"1.0"}}}' ``` ``` data: {"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2025-06-18","capabilities":{"tools":{"listChanged":false}},"serverInfo":{"name":"mcp-website-fetcher","version":"1.14.1"}}} ``` ## Step 5 — Discover and call a tool Use the [MCP Inspector](https://github.com/modelcontextprotocol/inspector) CLI to list the tools the gateway exposes: ```sh npx @modelcontextprotocol/inspector@0.21.2 --cli http://localhost:8080/mcp \ --transport http --method tools/list ``` ```json { "tools": [ { "name": "fetch", "description": "Fetches a website and returns its content", "inputSchema": { "type": "object", "properties": { "url": { "type": "string", "description": "URL to fetch" } }, "required": [ "url" ] } } ] } ``` Now call the tool through the gateway: ```sh npx @modelcontextprotocol/inspector@0.21.2 --cli http://localhost:8080/mcp \ --transport http --method tools/call --tool-name fetch --tool-arg url=https://example.com ``` ```json { "content": [ { "type": "text", "text": "<!doctype html><html lang=\"en\"><head><title>Example Domain</title>..." } ], "isError": false } ``` The tool ran and returned the page, routed through agentgateway. ## What the gateway adds A single `AgentgatewayBackend` can list several MCP targets, so the gateway federates many MCP servers behind one endpoint. Agents connect to that one endpoint and discover every tool, and you get a single point to apply access control and audit logging — the subject of part 6 of this series. ## Clean up ```sh kubectl delete httproute mcp kubectl delete agentgatewaybackend mcp-backend kubectl delete deployment,service mcp-website-fetcher ``` ## What’s next You routed a tool call through the gateway. Next, the gateway sits in front of model providers: you will route LLM traffic across providers — including a model running on your own machine — without changing your application. > Next in this series: [Routing LLM Traffic Across Providers](/learn/ai-infrastructure/routing-llm-traffic/). ## Summary - An `AgentgatewayBackend` with `mcp.targets` registers one or more MCP servers; mark the backend Service with `appProtocol: agentgateway.dev/mcp`. - An `HTTPRoute` whose `backendRef` names the `agentgateway.dev`/`AgentgatewayBackend` group/kind attaches it to the Gateway. - The gateway serves MCP over Streamable HTTP; clients `initialize`, `tools/list`, and `tools/call` through one endpoint. - One endpoint for many servers is where access control and audit logging later attach. #### Resources - [agentgateway MCP Docs](https://agentgateway.dev/docs/kubernetes/latest/mcp/static-mcp.md) - [Model Context Protocol](https://modelcontextprotocol.io/) - [MCP Inspector](https://github.com/modelcontextprotocol/inspector) #### On This Page - [Introduction](#introduction) - [Step 1 — Deploy a sample MCP server](#step-1--deploy-a-sample-mcp-server) - [Step 2 — Expose it with an AgentgatewayBackend](#step-2--expose-it-with-an-agentgatewaybackend) - [Step 3 — Attach a route](#step-3--attach-a-route) - [Step 4 — Connect to the MCP endpoint](#step-4--connect-to-the-mcp-endpoint) - [Step 5 — Discover and call a tool](#step-5--discover-and-call-a-tool) - [What the gateway adds](#what-the-gateway-adds) - [Clean up](#clean-up) - [What’s next](#whats-next) - [Summary](#summary) --- ## Kubermatic at KubeCon EU 2026: Scaling Kubernetes, AI, & Data Sovereignty - **URL:** https://www.kubermatic.com/resources/kubermatic-at-kubecon-eu-2026-scaling-kubernetes-ai-and-data-sovereignty/ - **Date:** 2026-06-05 - **Description:** Let's discuss how organizations can leverage Kubernetes to scale AI workloads, simplify day-two operations, and ensure data sovereignty across cloud and edge environments. # Kubermatic at KubeCon EU 2026: Scaling Kubernetes, AI, & Data Sovereignty ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Sebastian Scheele speak at KubeCon EU 2026 As environments grow in complexity, managing hundreds of clusters across cloud, data centers, and the edge requires a new approach. In this conversation, we explore how to simplify day-two operations with automation, the rising demand for data sovereignty, and why Kubernetes is becoming the unified platform for modern apps, virtual machines, and AI workloads. **Key Takeaways**: - Scaling & Automation: How to simplify operations for thousands of distributed clusters. - Unified Infrastructure: Running apps, legacy VMs, and AI on a single Kubernetes platform. - Data Sovereignty & Security: Maintaining control over your infrastructure and an introduction to the newly announced Kubernetes SecureGuard for secrets management. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## What Is an Agent Gateway? The Data Plane for Agentic AI - **URL:** https://www.kubermatic.com/learn/ai-infrastructure/what-is-agent-gateway/ - **Date:** 2026-06-17 [Learn](/learn/) / [Ai-Infrastructure](/learn/ai-infrastructure/) / What Is an Agent Gateway? The Data Plane for Agentic AI ai-infrastructure # What Is an Agent Gateway? The Data Plane for Agentic AI ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Jun 5, 2026 4 min read Beginner [getting-started](/learn/?tag=getting-started) [ai-infrastructure](/learn/?tag=ai-infrastructure) [agentic-ai](/learn/?tag=agentic-ai) #### Prerequisites - Basic understanding of Kubernetes concepts (Services, Ingress/Gateway API) - Familiarity with the idea of an API gateway or reverse proxy - A high-level sense of what AI agents and the Model Context Protocol (MCP) are ## Introduction Building with AI agents looks deceptively simple at first. You give an agent a tool, it calls the tool, it returns an answer. But the moment you have more than one agent, more than one model provider, or more than a couple of tools, you are running a small distributed system — and it generates network traffic that nobody is governing. This is the problem an **agent gateway** solves. If you have used an API gateway before, the idea will feel familiar: a single proxy that sits in front of your services and applies routing, authentication, and observability in one place. An agent gateway does the same job, but for the traffic patterns that *agentic* systems create. ## What is an agent gateway? An agent gateway is a **unified data plane for agent traffic**. It is a proxy that sits between your agents and everything they communicate with, and applies consistent routing, security, and observability across several kinds of traffic at once: - **MCP** — the Model Context Protocol calls an agent uses to discover and invoke tools. - **Agent-to-Agent (A2A)** — messages between agents, often across different frameworks. - **LLM inference** — calls to hosted model providers or to your own self-hosted models. - **Service traffic** — the ordinary HTTP, gRPC, and REST APIs agents still depend on. The gateway centralizes those concerns, so no agent re-implements authentication, retries, logging, and policy for each protocol. [agentgateway](https://agentgateway.dev/), an open-source project (Apache-2.0) now hosted by the Linux Foundation’s [Agentic AI Foundation](https://aaif.io/), describes this as “one high-performance gateway for service, LLM, and MCP traffic.” ## How is an agent gateway different from an API gateway? | | API gateway | Agent gateway | |---------------------|----------------------------|-----------------------------------------------------------| | **Primary traffic** | North-south HTTP/REST | MCP, A2A, LLM inference, *and* HTTP/gRPC | | **Unit of work** | A request | An agent *action* (tool call, inference, hand-off) | | **Routing** | Path/host → backend | Tool discovery, model/provider routing, inference routing | | **Policy concern** | Who may call this endpoint | Which agent may use which tool, with which arguments | | **Observability** | Request logs, latency | Tool-call audit, token usage, cross-agent traces | The old concerns remain. On top of them, the *unit of work* becomes an agent taking an action, which raises the stakes and adds new routing and policy needs. ## Key concepts ### The unified data plane One proxy handles multiple protocols (MCP, A2A, LLM, HTTP/gRPC) so policy and observability stay consistent across them, and the “AI parts” run through the same stack as everything else. ### MCP gateway A governed front door to your tools: discovery, RBAC, and audit logging for every Model Context Protocol call. ### LLM gateway One endpoint in front of multiple model providers, with token budgeting, caching, and failover, so switching providers is a configuration change with no agent code to rewrite. ### Inference routing Latency- and cost-aware routing of inference across self-hosted model servers (e.g. vLLM, TGI, Triton) on your own GPUs. ### Policy and observability Security controls (mTLS, authn/authz, policy-as-code) and telemetry (OpenTelemetry) applied uniformly to agent and traditional traffic. ## When should you use an agent gateway? - **You have more than one model provider** and want routing, budgeting, and failover without rewriting agents. - **You expose tools to agents over MCP** and need access control and an audit trail. - **You run agents across frameworks** and need them to communicate over A2A with consistent security. - **You self-host inference** and want to use GPU capacity deliberately. - **You need to govern or debug agent behavior** — one place that can answer “what did the agent do?” If your agentic system is a single agent calling a single tool, you do not need a gateway yet. The value shows up as soon as the system has more than one of anything. ## Where Kubernetes fits Agent gateways are typically built to run on Kubernetes. agentgateway, for instance, deploys via Helm and the Gateway API and is Envoy-compatible. The agentic data plane behaves like the rest of your platform. You deploy it declaratively, scale it horizontally, govern it with policy-as-code, and connect it to the networking you already run. Running it on Kubernetes keeps your agents’ most sensitive traffic on infrastructure you already operate and control, under one security and operational model. ## Next steps This is the first tutorial in the **Agent Gateway on Kubernetes** series. Next, we will deploy an agent gateway onto a cluster and route our first MCP tool call through it. > Upcoming in this series: *Installing an Agent Gateway on Kubernetes* → *Your First MCP Gateway* → *Routing LLM Traffic Across Providers* → *Agent-to-Agent Communication* → *Securing Agent Traffic with Policy and Observability*. ## Summary - An **agent gateway** is a unified data plane for agent traffic: MCP, agent-to-agent, LLM inference, and ordinary service calls. - It centralizes routing, security, and observability so each agent does not reinvent them — and it is the natural enforcement point for *which agent may do what*. - The main capabilities are MCP tool governance, multi-provider LLM routing, GPU-aware inference routing, A2A bridging, and unified policy/observability. - It is built for Kubernetes, keeping the agentic control plane on infrastructure you operate. #### Resources - [agentgateway Website](https://agentgateway.dev/) - [Agentic AI Foundation (AAIF)](https://aaif.io/) - [Model Context Protocol](https://modelcontextprotocol.io/) #### On This Page - [Introduction](#introduction) - [What is an agent gateway?](#what-is-an-agent-gateway) - [How is an agent gateway different from an API gateway?](#how-is-an-agent-gateway-different-from-an-api-gateway) - [Key concepts](#key-concepts) - [The unified data plane](#the-unified-data-plane) - [MCP gateway](#mcp-gateway) - [LLM gateway](#llm-gateway) - [Inference routing](#inference-routing) - [Policy and observability](#policy-and-observability) - [When should you use an agent gateway?](#when-should-you-use-an-agent-gateway) - [Where Kubernetes fits](#where-kubernetes-fits) - [Next steps](#next-steps) - [Summary](#summary) --- ## After VMware's CSP exit, what's next for Cloud Service Providers? - **URL:** https://www.kubermatic.com/blog/after-vmwares-csp-exit-whats-next-for-cloud-service-providers/ - **Date:** 2026-06-03 - **Description:** The VMware CSP program has ended. Learn how DACH cloud service providers are moving to open-source. - **Categories:** Best Practices - **Tags:** Open Source Projects - **Authors:** Joana Figueiredo ## What is happening with VMware and Cloud Service Providers? Broadcom's acquisition of VMware has brought major changes to its partner ecosystem. Since October 2025, Broadcom has formally ended VMware's Cloud Service Provider (VCSP) program and replaced it with a highly selective, invitation-only model centered on VMware Cloud Foundation (VCF). ## What does this mean for Cloud Service Providers? For many regional Cloud Service Providers (CSPs) and Managed Service Providers (MSPs), particularly across Germany, Switzerland, and the wider DACH region, this means they can no longer renew agreements or onboard new VMware customers. Many are now evaluating how to continue serving customers while maintaining profitability and compliance. ## What are the biggest consequences of the VMware CSP changes? The impact varies depending on whether a provider remains in VMware's ecosystem or not. ### Some providers are being forced to find an alternative Many regional providers were not invited into Broadcom's new partner model. As existing agreements expire, these providers must either migrate customers to a different platform, establish a new virtualization strategy, or risk losing their ability to offer VMware-based services altogether. ### Providers that remain face higher costs For providers that continue offering VMware services, the transition to VMware Cloud Foundation often requires adopting a broader and more expensive subscription model. Instead of licensing only the components they need, providers may be required to purchase a larger bundled platform, significantly increasing costs and pressure on margins. ## Is replacing VMware with another hypervisor the best long-term solution? Not necessarily. Replacing one proprietary hypervisor with another does not solve the underlying problem: vendor lock-in. Licensing models change. Vendors get acquired. Pricing increases. The risk remains the same. Instead of moving from one proprietary platform to another, many providers are using this moment to rethink their infrastructure strategy around open standards and open-source technologies. Additionally, there are [sovereignty concerns](/blog/is-europe-breaking-up-with-us-cloud-giants/). European organizations want to keep critical workloads under local control and reduce dependence on foreign-owned platforms. For Cloud Service Providers, sovereignty is increasingly becoming a competitive differentiator. ## What is the alternative to VMware? The answer is open source. The VMware changes have highlighted the risks of building a business around a single proprietary platform. One increasingly popular approach combines Kubernetes with KubeVirt. KubeVirt allows organizations to run traditional virtual machines alongside containerized applications within Kubernetes. This creates a unified platform for both legacy and cloud-native workloads. ## Why isn't KubeVirt alone enough? KubeVirt solves virtualization, but enterprise platforms require much more than a hypervisor. Organizations still need lifecycle management, automation, multi-tenancy, self-service capabilities, upgrades, security controls, and operational tooling to run production environments at scale. ## This is where Kubermatic comes in. We help Cloud Service Providers build and operate open, sovereign alternatives to VMware. Using Kubermatic Kubernetes Platform, Kubermatic Virtualization, and KubeVirt, we enable providers to run virtual machines and Kubernetes workloads on a single platform, without the licensing constraints and vendor lock-in of traditional virtualization stacks. ## Has this approach been proven in production? Yes. Swisscom, Switzerland's leading ICT provider, adopted this approach while building a next-generation cloud platform for highly regulated customers. Rather than extending its legacy virtualization environment, Swisscom chose to build a new platform based on Kubermatic Kubernetes Platform, Kubermatic Virtualization, and KubeVirt. The resulting architecture has been [recognized by the Cloud Native Computing Foundation](https://architecture.cncf.io/architectures/swisscom-kubernetes-service/) (CNCF) as an example of large-scale cloud-native infrastructure modernization. ## How did Swisscom build a sovereign cloud platform with Kubermatic? Swisscom's goal was to build a modern platform that could support both existing virtual machine workloads and cloud-native applications while maintaining full control over its infrastructure and data. Together with Kubermatic, Swisscom [built an open-source platform](/customers/swisscoms-journey-from-vendor-lock-in-to-cloud-native-infrastructure-platform/) based on Kubermatic Kubernetes Platform (KKP) and KubeVirt, creating a single operating model for both VMs and Kubernetes. Most importantly, the platform remains fully operated by Swisscom, in Switzerland, under Swiss jurisdiction. ## What were the results? Swisscom successfully launched its Kubernetes platform as the company's internal container platform. The new platform provides self-service provisioning, automated scaling, faster updates, improved resilience, and reduced dependence on proprietary vendors. For Swisscom and its customers, the result is a modern cloud platform with full control over infrastructure and data. ## How long did the migration take? Swisscom achieved adoption quickly. Within the first nine months of operation, more than 60% of targeted workloads had already been migrated to the new platform. ## What are the biggest concerns when migrating away from VMware? For most organizations, the biggest challenge is not choosing an alternative. It is managing the migration risk. The good news is that most VMware workloads can be migrated successfully. The key is understanding which workloads can move as-is, which should be modernized, and which require additional planning. ## Will my virtual machines still work? In most cases, yes. KubeVirt allows organizations to run traditional virtual machines without changing the applications running inside those VMs. This enables organizations to preserve existing investments while modernizing the underlying infrastructure. ## Do all workloads need to be migrated as virtual machines? No. Many organizations discover that some workloads are better suited for containers. A VMware migration project is often an opportunity to identify which applications should remain virtual machines and which can be modernized into cloud-native services. Most successful migrations use a combination of both approaches. ## How can organizations reduce migration risk? At Kubermatic, we implement a [phased migration approach](/resources/four-phases-for-a-successful-vmware-migration/): 1. **Uncover** - Create a complete inventory of VMware workloads and dependencies. 1. **Analyze** - Identify compatibility requirements, networking considerations, and modernization opportunities. 1. **Pilot** - Migrate a small set of workloads to validate performance and operational processes. 1. **Plan and Scale** - Execute a phased rollout based on lessons learned from the pilot. This approach minimizes disruption, preserves rollback options, and reduces risk throughout the migration process. ## Why is this a defining moment for European cloud infrastructure? The end of the VMware CSP ecosystem represents more than a licensing change. It is forcing providers to rethink sovereignty, vendor dependence, and long-term platform strategy. Swisscom's experience shows that there is an alternative: a sovereign, open-source platform that supports both virtual machines and cloud-native applications without creating a new dependency on proprietary technology. ## How can organizations get started with a VMware alternative? Start with an assessment. Identify which workloads need to remain virtual machines, which can be modernized into containers, and which business, compliance, or sovereignty requirements must be met. From there, run a small pilot before committing to a large-scale migration. This helps validate performance, operational processes, and migration paths while minimizing risk. At Kubermatic, we help Cloud Service Providers assess their VMware footprint, build a migration strategy, and implement sovereign cloud platforms based on Kubermatic Kubernetes Platform, Kubermatic Virtualization, and KubeVirt. ## About Kubermatic Kubermatic is a Germany-based open-source company helping Cloud Service Providers and enterprises build sovereign cloud platforms. Built on Kubernetes and KubeVirt, our solutions enable organizations to run virtual machines and cloud-native workloads on a unified platform while avoiding vendor lock-in. Trusted by leading providers such as Swisscom and recognized as a top European contributor to the CNCF ecosystem, Kubermatic helps organizations modernize their infrastructure while maintaining full control over their data, operations, and future technology choices. --- ## Seamless AI-as-a-Service across Kubernetes Clusters With Envoy AI Gate - **URL:** https://www.kubermatic.com/resources/seamless-ai-as-a-service-across-kubernetes-clusters-with-envoy-ai-gate/ - **Date:** 2026-05-29 - **Description:** Discover how to combine Envoy AI Gateway and kube-bind into a "Provider-Consumer" architecture. # Seamless AI-as-a-Service across Kubernetes Clusters With Envoy AI Gate ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Learn how to securely share and scale AI models across multiple Kubernetes clusters. Discover how to combine Envoy AI Gateway and kube-bind into a “Provider-Consumer” architecture, allowing remote engineering teams to safely consume centralized GPU models using standard Kubernetes resources without sharing API keys. **Speakers: Karol Szwaj, Senior Software Engineer, Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Move Beyond VMware - **URL:** https://www.kubermatic.com/solutions/move-beyond-vmware/ - **Date:** 2026-07-08 - **Description:** Eliminate the hypervisor tax. Discover how Kubermatic Virtualization lets you natively run legacy VMs and container workloads side by side on Kubernetes. # Your VM Workloads, Cloud-Native Ready We deliver the migration layer that moves legacy VMs to Kubernetes without disruption, without lock-in. [Talk to an expert](/contact-sales/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Move Beyond VMware: Unify Your Infrastructure with Kubermatic ### Situation ### The Broadcom Ultimatum and the Hypervisor Tax Broadcom’s acquisition of VMware has fundamentally reshaped the virtualization landscape. For enterprise organizations, migrating away from VMware has shifted from a long-term strategic option to an urgent economic mandate. **Recent licensing and forced bundling strategies have introduced "hypervisor taxes" with reported cost increases of 200% to 1000%.** *Source: Avasant, 2025* **35% of VMware workloads will migrate to other platforms by 2028.** *Gartner, The CIO's Guide to Broadcom's Acquisition of VMware* For many organizations, staying on VMware is now more expensive and riskier than moving away. **The Challenge:** Enterprises face a narrow window to act, but migration is fraught with operational risk: - **Proprietary Silos:** Replacing VMware with another proprietary stack offers no functional improvement. - **Tooling Overhead:** Maintaining separate environments and separate teams for Virtual Machines (VMs) and modern containers drains IT budgets. - **Disruption Risk:** Migration requires careful coordination and planning across teams and executives. Migration errors can disrupt critical systems. ### How we help ### The Unified KubeVirt Platform Kubermatic enables a structured, de-risked escape route from VMware. We do not offer a simple “like-for-like” hypervisor replacement; we deliver true platform unification. By integrating **KubeVirt** technology directly into the **Kubermatic Kubernetes Platform (KKP)**, organizations can natively run legacy virtual machines alongside cloud-native container workloads within a single environment. **The Architectural Shift:** Kubermatic unifies compute, storage, and networking under the universal Kubernetes API, replacing proprietary VMware components with open-source, declarative equivalents: | Legacy vSphere Concept | Kubermatic (KubeVirt) Equivalent | The Business Outcome | |------------------------|-------------------------------------|-------------------------------------------------------------------------------| | **vCenter Server** | Kubernetes API (Control Plane) | Shift from proprietary GUIs to automated, GitOps-driven workflows. | | **ESXi Hypervisor** | KVM/QEMU in a virt-launcher Pod | The hypervisor becomes a process inside a pod, fully scheduled by Kubernetes. | | **Datastore (vSAN)** | PersistentVolumeClaim (PVC) via CSI | Break free from monolithic storage; utilize any standard storage backend. | | **vSwitch / VLAN** | CNI + Multus | Software-defined networking mapping legacy VLANs directly into Kubernetes. | | **vMotion** | KubeVirt Live Migration API | Seamless workload mobility with zero downtime. | ### The Migration Path The biggest challenge is not the technical move itself. It is the operational mindset shift required across teams. Kubermatic Virtualization provides a gradual, 4-phase migration path: ### 1. Assessment and Strategy Build a comprehensive VM inventory and establish performance baselines. Classify workloads to **retire**, **refactor**, or **rehost** (lift-and-shift) while identifying a low-risk pilot to validate the approach. ### 2. Platform Foundation and Pilot Deploy the KubeVirt platform including KKP, storage (CSI), and networking (Multus). Conduct a controlled pilot to verify critical features like **Live Migration** and **High Availability**, resulting in a repeatable migration runbook. ### 3. Scaled Execution Migrate workloads in organized waves. Use **Rehost** for fast, "as-is" transfers of legacy apps, or **Refactor** for high-value applications that require cloud-native optimization. ### 4. Optimization and Day-2 Governance Fine-tune resources post-migration and implement **GitOps** for unified VM and container management. Finally, decommission legacy vSphere resources to fully realize TCO savings. ## Real-World Use Cases **Legacy Application Rehosting (Immediate Cost Relief)** - **The Mission:** Eliminate VMware licensing costs immediately without modifying legacy application code. - **The Application:** Lift-and-shift monolithic applications directly into KubeVirt pods. The legacy VM runs exactly as before, but the “hypervisor tax” is entirely eliminated. **Gradual Application Modernization (Refactoring)** - **The Mission:** Modernize legacy systems without disrupting mission-critical business operations. - **The Application:** Run existing VMs on the Kubermatic platform to establish a stable baseline. Over time, engineering teams can progressively decompose the monolithic VM into modern microservices, side-by-side on the exact same platform. **Unified Edge Operations** - **The Mission:** Standardize operations across highly distributed environments like retail stores or factory floors. - **The Application:** Run both legacy VM-based systems (like Windows point-of-sale or MES) and modern containerized AI workloads together at the edge, managed via a single centralized interface. Kubermatic helped Swisscom escape VMware and build a 100% sovereign, open-source Kubernetes service. [Explore Success Story](/customers/swisscoms-journey-from-vendor-lock-in-to-cloud-native-infrastructure-platform/) [Discover CNCF recognition](https://architecture.cncf.io/architectures/swisscom-kubernetes-service/) 60% of workloads migrated within 9 months 100% Sovereign Cloud Architecture ### Outcome ### Zero Tax, Unified Teams, and Total Freedom By migrating from VMware to Kubermatic, organizations transition from restrictive legacy virtualization to an agile, future-proofed cloud-native foundation. ### Zero Hypervisor Tax Instantly eliminate costly, proprietary VMware subscriptions and avoid forced product bundling. ### Operational Unification Merge “Team VM” and “Team Container” into a single Platform Engineering unit. Manage VMs using modern GitOps and Ansible automation — treating legacy infrastructure as code. ### Strategic Flexibility (No Vendor Lock-in) Standardize entirely on the open Kubernetes API. Run your workloads anywhere — on bare metal, in the public cloud, or at the edge — on any certified hardware. ### De-Risked Migration Balance financial pressure with operational safety by utilizing our structured pilot-to-scale runbooks, ensuring high availability during the transition. ## Why Kubermatic? ![Proven Leadership](/static/defence-architecture.png) ### Proven Leadership Recognized by Gartner®, Forrester, GigaOM, SPARK Matrix™ and a top contributor to the CNCF. ![Flexibility](/static/defence-why-kubermatic.png) ### Flexibility Supports Bare Metal, vSphere, OpenStack, and all major public clouds (AWS, Azure, GCP). ![Sovereignty](/static/phone-policeman-lock.png) ### Sovereignty Germany-based company offering 100% sovereign infrastructure and secure, private cloud stacks. ![People builds the program](/static/people-builds-the-program.svg) ### Expert Support Implementation, managed services, and 24×7 mission support from Kubernetes experts. ## Discover more resources ![](/static/clock-grad-icon.svg) ### [The Four Phases for a Successful VMware Migration](/resources/four-phases-for-a-successful-vmware-migration/) ![](/static/icons/search-blue-icon.svg) ### [Planning Your VMware to KubeVirt Migration](/learn/kubevirt/vmware-to-kubevirt-migration-planning/) ![](/static/bar-chart-icon-blue-grad.svg) ### [Strategic Paths for CIOs After Broadcom's VMware Acquisition](/solution-brief-strategic-paths-for-cios-after-broadcoms-vmware-acquisition/) ![](/static/sheets-icon-blue.svg) ### [The Great Migration: From VMware to Kubernetes, Tooling and Practices](/blog/the-great-migration-from-vmware-to-kubernetes-tooling-and-practices/) ![](/static/person-speaks-icon-blue-grad.svg) ### [After VMware's CSP exit, what's next for Cloud Service Providers?](/blog/after-vmwares-csp-exit-whats-next-for-cloud-service-providers/) ![](/static/icons/kubernetes-icon.svg) ### [Explore Your Kubernetes-Native Virtualization with Kubermatic](/info/vmware-alternative/) ![](/static/icons/bulb-blue-icon.svg) ### [Meet Kubermatic Virtualization](/products/kubermatic-virtualization/) ![](/static/icons/cert-icon.svg) ### [CNCF Case Study: Swisscom Success Story](/customers/swisscoms-journey-from-vendor-lock-in-to-cloud-native-infrastructure-platform/) --- ## Automated Kubernetes Backups - **URL:** https://www.kubermatic.com/solutions/kubernetes-backups/ - **Date:** 2026-07-08 - **Description:** Empower project owners with self-service data protection. Discover how Kubermatic handles cross-cluster disaster recovery and instance migrations. # Automated Kubernetes Backups We ensure the automated backup, recovery, and migration of your Kubernetes clusters. [Talk to an expert](/contact-sales/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Automated Backup & Recovery ### Situation ### The Kubernetes Backup Problem Kubernetes changed how infrastructure is deployed and operated, but backup and recovery processes still rely on outdated approaches. Traditional backup systems were not built for dynamic workloads, distributed data, or rapidly changing cluster environments. As a result, teams often depend on manual processes and direct access to etcd databases. This creates operational bottlenecks, slows down DevOps teams, and increases the risk of data loss. Migrating workloads and persistent data between cloud and on-premises environments is also complex. Many solutions only support full cluster restores and require time-consuming manual cleanup, adding unnecessary operational overhead. **By 2029, 75% of enterprises will use a common solution for backup and recovery of data residing on-premises and in cloud infrastructure, compared with 25% in 2025.** *Gartner, Critical Capabilities for Backup and Data Protection Platforms, 9 July 2025* ### How we help ### Self-Service, Automated, Cross-Cluster Recovery Kubermatic Kubernetes Platform (KKP) provides a built-in backup and restore system that gives project owners full control over their Kubernetes backups. Teams can configure, run, and restore backups directly through KKP without relying on platform administrators or direct etcd access. KKP’s architecture reduces administrative overhead, improves recovery times, and simplifies Kubernetes migrations while minimizing operational risk and downtime during incidents or infrastructure transitions. **Key capabilities of KKP Backup:** ### Self-Service Backup and Restore Project owners manage backups, restores, schedules, retention policies, storage locations, and namespace selection independently, without requiring platform administrator involvement. ### Automated Backups KKP automates backup scheduling, retention management, and cleanup of outdated backup sets. Project owners define schedules and retention policies once, while KKP continuously handles execution and cleanup in the background. Selective namespace backup and restore also protect critical workloads without requiring full-cluster backups. ### Disaster Recovery KKP enables fast recovery of applications and data from backups, including selective namespace recovery, without requiring full-cluster restores or manual reconstruction. ### Cluster Migration KKP restores backups into different KKP instances across on-premises and cloud environments, supporting migrations, disaster recovery, infrastructure transitions, and data center moves. ### Velero-based backup engine KKP leverages Velero and the Kubernetes API to capture Kubernetes resources, persistent volumes, and snapshots in configurable external storage locations. This Kubernetes-native backup architecture enables reliable recovery, data integrity, and backup operations across cloud and on-premises environments. ## Use Cases **Self-Service Disaster Recovery** - **The Mission:** Empower project owners to manage their own backup schedules and execute recoveries independently without waiting for platform admin availability during incidents. - **The Application:** KKP’s project-level backup management gives project owners full control over backup schedules, storage destinations, TTLs, and namespace selection. During a recovery event, project owners initiate restore operations directly from the KKP dashboard, without raising a platform admin ticket. **Cross-Instance Cluster Migration** - **The Mission:** Migrate Kubernetes workloads from an on-premises KKP instance to a cloud-hosted KKP instance, preserving all persistent data and application state without manual reconstruction. - **The Application:** KKP’s Velero-based backup captures cluster state, volumes, and Kubernetes manifests to external storage accessible by both KKP instances. Backups restore directly into the target environment with namespace structure and persistent data intact, eliminating manual export/import workflows and simplifying migrations. **Automated Namespace-Level Data Protection** - **The Mission:** Protect critical application namespaces on individual backup schedules — with higher frequency and longer retention than cluster-level backup policies without backing up non-critical workloads at the same cost. - **The Application:** KKP’s selective namespace backup and restore lets project owners define per-namespace backup policies. For example, production databases can back up hourly with long retention, while development namespaces back up less frequently. Individual namespaces restore independently without affecting unrelated workloads. [Discover Success Stories](/customers/) ### Outcome ### Reliable Kubernetes Backup & Recovery at Scale By standardizing on KKP’s backup and recovery capabilities, organizations replace manual, admin-dependent backup workflows with automated, project-owner-controlled data protection — covering on-premises and cloud environments identically. ### Project Owners Control Their Own Data Decentralized backup management empowers project teams to set schedules, retention policies, and storage locations independently. Platform admins are freed from routine backup requests, focusing on platform architecture instead of data management tickets. ### Cross-Instance Migration Flexibility Restore cluster backups to completely different KKP instances — enabling data center migrations, environment transitions, and disaster recovery across separate infrastructure without manual data reconstruction. ### Automated Backup Execution and Cleanup Regular backups run on configured schedules without manual initiation. Old backup sets are automatically deleted based on retention policies, optimizing storage costs and ensuring backup sets remain usable without growing unbounded. ### Namespace-Level Granularity Selectively backup and restore specific namespaces, protecting critical production data on tight schedules without paying backup costs for ephemeral development workloads. Recovery targets exactly the namespace that failed, not the entire cluster. ## Why Kubermatic? ![Proven Leadership](/static/defence-architecture.png) ### Proven Leadership Recognized by Gartner®, Forrester, GigaOM, SPARK Matrix™ and a top contributor to the CNCF. ![Flexibility](/static/defence-why-kubermatic.png) ### Flexibility Supports Bare Metal, vSphere, OpenStack, and all major public clouds (AWS, Azure, GCP). ![Sovereignty](/static/phone-policeman-lock.png) ### Sovereignty Germany-based company offering 100% sovereign infrastructure and secure, private cloud stacks. ![People builds the program](/static/people-builds-the-program.svg) ### Expert Support Implementation, managed services, and 24×7 mission support from Kubernetes experts. --- ## Control Your Data Sovereignty - **URL:** https://www.kubermatic.com/solutions/control-your-data-sovereignty/ - **Date:** 2026-07-08 - **Description:** Data residency is not data sovereignty. Discover how Kubermatic provides full jurisdictional control over your infrastructure control planes and data. # Control Your Data Sovereignty We build sovereign infrastructure to give you back full control over your data and operations. [Talk to an expert](/contact-sales/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Sovereign Cloud Infrastructure with Kubermatic ### Situation ### Data Residency Is Not Data Sovereignty Many organizations assume that storing data in a European data center makes it sovereign. It does not. Under the [U.S. CLOUD Act](/blog/is-europe-breaking-up-with-us-cloud-giants/), American authorities can compel any U.S.-headquartered cloud provider to hand over data — regardless of where that data is physically stored. This means that even if your workloads run in Frankfurt or Amsterdam, a U.S. hyperscaler can still be legally required to disclose them. The problem runs deeper than legal exposure. Many cloud services marketed as ‘sovereign’ still depend on control planes, identity systems, or key management hosted outside the customer’s jurisdiction. That creates a hidden dependency and a real compliance risk, even when the underlying data appears to be local. At the same time, organizations face tightening regulatory obligations, including the EU Data Act and DORA, the Swiss nFADP. Additionally, government and critical infrastructure organizations face pressure to demonstrate that foreign authorities have no legal access to their systems. As a result, [enterprises are rethinking their cloud strategies](/blog/the-new-era-of-resilience-in-the-cloud/). Vendor lock-in, foreign legal exposure, and opaque dependency chains are no longer acceptable. Organizations need infrastructure they actually control. **By 2030, More Than 75% of All Enterprises Outside of the U.S. Will Have a Digital Sovereignty Strategy.** *Source: [Gartner](https://www.gartner.com/en/newsroom/press-releases/2025-11-12-gartner-survey-reveals-geopolitics-will-drive-61-percent-of-cios-and-information-technology-leaders-in-western-europe-to-increase-reliance-on-local-cloud-providers), Gartner Survey, 2025* ### How we help ### Architecture-First Sovereignty Kubermatic enables organizations to build resilient, sovereign cloud platforms with full control over their data, operations, and infrastructure. Using proven CNCF open-source technologies, we provide the foundation for a “Second Platform Strategy” that reduces dependency on foreign hyperscalers while keeping critical systems and operations within your jurisdiction. ### Kubermatic Kubernetes Platform (KKP) KKP automates the full Kubernetes lifecycle across cloud, on-premises, and edge environments. This allows organizations to operate large-scale infrastructure consistently while maintaining strict data residency and operational control. ### Decoupled Control Planes True sovereignty requires control over the management layer of your infrastructure. KKP separates the control plane from workload environments, allowing organizations to run management systems in sovereign private clouds or air-gapped environments while maintaining flexibility across regions and providers. ### Kubermatic Virtualization Powered by KubeVirt, Kubermatic Virtualization helps organizations modernize infrastructure while maintaining full operational control. By running virtual machines and cloud-native applications on the same platform, organizations can reduce dependency on proprietary virtualization vendors, avoid restrictive licensing models, and keep critical infrastructure under their own control. ### Kubermatic SecureGuard Built on OpenBao, Kubermatic SecureGuard ensures that your encryption keys and security credentials remain exclusively under your control, entirely removing dependence on foreign or proprietary key management systems. ## Use Cases **Launching a Sovereign Cloud Service** - **The Mission:** Build a multi-tenant cloud platform that guarantees 100% regional data residency while matching the performance and agility of global hyperscalers. - **The Application:** Telecom and public sector providers use KKP, KubeOne, and KubeVirt to build highly available sovereign infrastructure on open-source foundations. Swisscom, for example, migrated 60% of internal workloads within nine months, demonstrating that sovereign platforms can deliver enterprise-scale performance without foreign dependencies. This architecture was [recognized by the CNCF](https://architecture.cncf.io/architectures/swisscom-kubernetes-service/) as a leading example. **Digital Sovereignty by Design** - **The Mission:** Meet stringent regional financial and cybersecurity regulations without creating operational bottlenecks or slowing down developer velocity. - **The Application:** Regulated enterprises use KKP to deliver automated “Golden Paths” — pre-configured, fully compliant platform building blocks for developers. By combining this with Kubermatic SecureGuard for automated secret rotation and identity-based access, financial institutions can strictly adhere to frameworks like **DORA, SOC 2, and the Swiss nFADP**, eliminating the legal risk of foreign data access. **Sovereign Multi-Cloud for Government** - **The Mission:** Build an independent IT ecosystem across multiple cloud providers and on-premises data centers to ensure sensitive data remains entirely outside the jurisdiction of foreign authorities. - **The Application:** Government bodies and critical infrastructure providers utilize the Platform Mesh architecture within KKP to consume services across multiple isolated control plane instances. [Discover Success Stories](/customers/) ### Outcome ### Absolute Autonomy and Resilience By standardizing on Kubermatic’s architecture-first sovereign infrastructure, organizations replace foreign legal exposure and opaque dependencies with a truly autonomous cloud foundation. ### Jurisdictional Freedom Maintain control over critical infrastructure, data, and operations while reducing exposure to foreign legal jurisdiction and external dependencies. ### Cost Avoidance Build portable cloud infrastructure on open-source technologies, avoiding dependency on proprietary platforms and costly vendor-specific licensing models. ### Operational Resilience Operate workloads consistently across cloud, on-premises, and edge environments with the flexibility to adapt infrastructure strategies as regulatory, political, or operational conditions evolve. ### Future-Proofing for AI Standardize on Kubernetes-based infrastructure to run AI workloads across cloud, on-premises, and edge environments while maintaining operational control and compliance. ## Why Kubermatic? ![Proven Leadership](/static/defence-architecture.png) ### Proven Leadership Recognized by Gartner®, Forrester, GigaOM, SPARK Matrix™ and a top contributor to the CNCF. ![Flexibility](/static/defence-why-kubermatic.png) ### Flexibility Supports Bare Metal, vSphere, OpenStack, and all major public clouds (AWS, Azure, GCP). ![Sovereignty](/static/phone-policeman-lock.png) ### Sovereignty Germany-based company offering 100% sovereign infrastructure and secure, private cloud stacks. ![People builds the program](/static/people-builds-the-program.svg) ### Expert Support Implementation, managed services, and 24×7 mission support from Kubernetes experts. --- ## Implement Platform Engineering - **URL:** https://www.kubermatic.com/solutions/implement-platform-engineering/ - **Date:** 2026-07-08 - **Description:** Move beyond the UI portal trap. Discover how Kubermatic Developer Platform uses Kubernetes-native automation to unlock true developer self-service. # Implement Platform Engineering We provide the infrastructure power to make developer self-service a reality. [Talk to an expert](/contact-sales/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Architecting your Internal Developer Platform ### Situation ### The Portal Trap **By 2026, 80% of large software engineering organizations will establish platform engineering teams as internal providers of reusable services, components, and tools for application delivery.** *Gartner, [Top Tech Trends Unpacked, Platform Engineering](https://www.gartner.com/en/experts/top-tech-trends-unpacked-series/platform-engineering-empowers-developers), 2024* As organizations move beyond the initial hype of platform engineering, a common problem has emerged: many initiatives stall because teams build portals when they actually need platforms. Early Internal Developer Platforms (IDPs) improved service discovery, but developers still depend on manual approvals, ticket queues, and platform teams to provision infrastructure. At the same time, infrastructure complexity continues to grow: - Developers are expected to manage Kubernetes, CI/CD pipelines, cloud configurations, and security policies alongside application development. - Platform teams struggle to provide secure multi-tenant environments and governance without increasing operational overhead. - Self-service remains limited, and engineering teams spend too much time managing infrastructure instead of building software. The result is a growing gap between the promise of developer self-service and the reality of day-to-day operations. ### How we help ### Kubermatic Developer Platform (KDP) Kubermatic Developer Platform (KDP) is an industrialized IDP built from the infrastructure up, not the UI down. Built on the CNCF Sandbox project **kcp**, KDP provides a Kubernetes-native control plane that transforms internal IT into a service-oriented marketplace. ### "Kubernetes-in-Kubernetes" Architecture KDP leverages **kcp workspaces** — lightweight, logical clusters that operate as independent API servers. This provides hard multi-tenancy at the control plane level without the overhead of thousands of physical clusters. ### A Service Catalog that Provisions Unlike simple catalogs, KDP uses the **api-syncagent** to bidirectionally sync resource requests from the central control plane to distributed service clusters. Developers get running resources (databases, queues, AI models) in seconds, not days. ### Standardized API Governance KDP uses standard Kubernetes APIs all the way down. If a team knows `kubectl`, they know KDP. This eliminates the need for proprietary SDKs or complex TypeScript plugins. ### Agentic-Ready Infrastructure KDP is engineered for the era of AI. Its machine-readable APIs and AI Assistant allow both humans and autonomous agents to discover and provision resources via natural language. ## Use Cases **Self-Service Database-as-a-Service (DBaaS)** - **The Mission:** Eliminate the 3-day wait for a PostgreSQL database. - **The Application:** Service owners define a `PublishedResource` via Crossplane. Developers select the service from the KDP dashboard, and KDP automatically provides the managed cloud instance (AWS RDS, GCP SQL) or on-prem database, delivering connection details directly to the developer’s workspace. **AI ModelOps and Governance** - **The Mission:** Control access to high-value AI models and GPU compute. - **The Application:** Platform teams use KDP workspaces to isolate AI workloads. They publish LLM endpoints to specific teams through the catalog, managing GPU quotas and token rotation via [Kubermatic SecureGuard](/products/kubermatic-secureguard/) to prevent cost overruns and hard-coded leaks. **Enterprise Multi-Tenancy at Scale** - **The Mission:** Supporting thousands of teams without cluster sprawl. - **The Application:** Utilizing the hierarchical workspace model, platform owners manage the root, while individual departments manage their own branches. Each team operates in its own API space, completely invisible to others, drastically reducing the blast radius of misconfigurations. [Discover Success Stories](/customers/) ### Outcome ### Speed, Simplicity, and Power By implementing platform engineering with KDP, organizations replace manual toil with an automated software delivery engine. ### Near-Zero Wait Times Transition from ticket-based provisioning to one-click service creation, reducing delivery times from days to seconds. ### 70% Reduction in Operational Overhead Shift the focus of DevOps teams from “putting out fires” to building “golden paths,” enabling a single engineer to manage hundreds of clusters. ### Enhanced Developer Velocity Reclaim up to 3 hours per week per developer by automating secret management and infrastructure tasks. ### Future-Proof Scalability A hardware-agnostic platform that supports any Kubernetes cluster across multi-cloud, on-prem, and edge environments. ## Why Kubermatic? ![Proven Leadership](/static/defence-architecture.png) ### Proven Leadership Recognized by Gartner®, Forrester, GigaOM, SPARK Matrix™ and a top contributor to the CNCF. ![Flexibility](/static/defence-why-kubermatic.png) ### Flexibility Supports Bare Metal, vSphere, OpenStack, and all major public clouds (AWS, Azure, GCP). ![Sovereignty](/static/phone-policeman-lock.png) ### Sovereignty Germany-based company offering 100% sovereign infrastructure and secure, private cloud stacks. ![People builds the program](/static/people-builds-the-program.svg) ### Expert Support Implementation, managed services, and 24×7 mission support from Kubernetes experts. --- ## Automate with AI - **URL:** https://www.kubermatic.com/solutions/automate-with-ai/ - **Date:** 2026-07-08 - **Description:** Transform raw compute into a governed AI platform. Discover how Kubermatic AI PaaS maximizes your GPU ROI with zero vendor lock-in. # Automate with AI We deliver the software layer that transforms raw compute into a governed, self-service AI platform. [Talk to an expert](/contact-sales/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Kubermatic AI PaaS: Maximum GPU ROI, Zero Lock-In ### Situation ### Raw Compute Is Not Enough Enterprises are moving fast on AI, but most hit the same wall. GPU clusters are procured, pilots are running, yet production AI at scale remains out of reach. The problem is not compute, it is the lack of a unified software layer to orchestrate distributed workloads, manage multi-tenant isolation, and enforce governance. Closing that gap isn’t just an operational priority, it’s a strategic one. Gartner puts it plainly: **By 2030, intelligent agents will orchestrate infrastructure, applications and business processes. Humans set intents, and guardrails agents decide, allocate, operate and self-optimize across cloud, edge and on-premises.** *Source: Gartner, The Future of I&O 2030: The Impact of AI* ![Six Gartner Positions on the Future of I&O 2030: The Impact of AI](/static/gartner-future-of-io-2030-impact-of-ai.png) *Source: Gartner, The Future of I&O 2030: The Impact of AI* **The Challenge:** - **Operational silos:** Data science, IT, and security teams operate with separate tools and environments, leaving expensive GPU resources chronically underutilised. - **The deployment bottleneck:** Moving a model from training to production requires manual handoffs and inconsistent environments, stretching cycles from days to weeks. - **The governance gap:** Without centralised visibility and policy enforcement, AI workloads proliferate across environments, creating compliance exposure and uncontrolled costs. ### How we help ### Kubermatic as Your AI Factory Operating System Kubermatic transforms disparate GPU infrastructure — bare metal, on-premises, or hybrid multi-cloud — into a cohesive, self-service AI factory. Data scientists get instant self-service access. Platform engineers retain granular control over high-value GPU resources. Everyone works from the same platform. ### Self-Service Developer Portal Data science teams provision logical Kubernetes workspaces instantly via a natural language AI agent that translates prompts into configurations. Teams focus on models, not cluster administration. ### GPU Orchestration Native NVIDIA GPU Operator integration ensures AI workloads access GPU resources directly, bypassing hypervisor overhead. Bare-metal provisioning is fully automated. ### High-Performance Workloads Disaggregated inference splits LLM workloads into prefill and decode phases, scaling independently to increase throughput without additional hardware. HPC-grade gang scheduling handles massive training jobs with deterministic, topology-aware placement, eliminating the deadlocks standard Kubernetes schedulers cannot resolve. ### AI Network Fabric An AI-aware load balancer routes inference traffic based on real-time GPU telemetry and cache saturation with semantic caching, token rate limits, and prompt guardrails enforced at the network layer. ### Security LLM API keys and model credentials are managed with automated, zero-downtime rotation via [Kubermatic SecureGuard](/products/kubermatic-secureguard/). ## Use Cases **Enterprise AI Factory** - **The Mission:** Eliminate silos between IT, security, and data science without sacrificing governance or GPU utilisation. - **The Application:** Self-service GPU workspaces for data scientists, centralised resource quotas and policy controls for platform teams, and automated lifecycle management for all AI workloads — training, fine-tuning, and inference — from one control plane. **Neocloud Providers: From Bare Metal to Managed AI Service** - **The Mission:** Move from low-margin GPU leasing to a high-margin, turn-key enterprise AI platform. - **The Application:** Kubermatic sits directly atop bare-metal GPU infrastructure, automating provisioning and exposing a self-service portal so enterprise customers deploy RAG pipelines and inference endpoints instantly without hardware management overhead. **Sovereign AI** - **The Mission:** Train and deploy AI on fully sovereign, on-premises infrastructure with strict data residency and no foreign cloud dependencies. - **The Application:** Kubermatic deploys entirely on-premises or air-gapped. SecureGuard protects credentials with automated rotation. HPC scheduling maximises utilisation of limited local GPU pools. Data never leaves the controlled environment. **Telecommunications: Legacy Networks Meet Edge AI** - **The Mission:** Run legacy VM-based network functions and modern AI workloads on the same infrastructure without separate stacks or teams. - **The Application:** [Kubermatic Virtualization](/products/kubermatic-virtualization/) encapsulates traditional VMs into Kubernetes pods, running them alongside containerised AI inference workloads at the network edge — managed centrally across thousands of distributed sites. [Discover Success Stories](/customers/) ### Outcome ### Maximum GPU ROI and Fluid Portability By standardizing on the Kubermatic AI PaaS, enterprises replace fragmented environments with a unified, open software layer that maximizes hardware value and accelerates delivery. ### Maximum GPU Utilisation Intelligent scheduling and disaggregated inference eliminate idle GPU time across teams. ### Weeks to Hours Deployment Automated lifecycle management removes manual handoffs, cutting deployment cycles from weeks to hours. ### Governed AI at Scale Centralised policy enforcement and audit trails across every workload and environment. ### No Lock-In Kubernetes AI Conformance guarantees workloads are freely portable across Neoclouds, private clouds, and on-premises — wherever GPU costs are lowest. ## Why Kubermatic? ![Proven Leadership](/static/defence-architecture.png) ### Proven Leadership Recognized by Gartner®, Forrester, GigaOM, SPARK Matrix™ and a top contributor to the CNCF. ![Flexibility](/static/defence-why-kubermatic.png) ### Flexibility Supports Bare Metal, vSphere, OpenStack, and all major public clouds (AWS, Azure, GCP). ![Sovereignty](/static/phone-policeman-lock.png) ### Sovereignty Germany-based company offering 100% sovereign infrastructure and secure, private cloud stacks. ![People builds the program](/static/people-builds-the-program.svg) ### Expert Support Implementation, managed services, and 24×7 mission support from Kubernetes experts. --- ## Telecom Solution - **URL:** https://www.kubermatic.com/solutions/telecom/ - **Date:** 2026-07-08 - **Description:** Kubermatic powers autonomous, carrier-grade networks for CSPs. From 5G core to far edge, one platform for Level 4 Autonomous Networks, edge monetization, and Sovereign AI infrastructure. # Telecom Solution Built for CSPs leading the AI economy. [Talk to an expert](/contact-sales/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Scalable, Sovereign Infrastructure for Modern Telco ### Situation ### A New Era of Opportunity for CSPs Edge monetization, enterprise private 5G, and AI-ready infrastructure are the fastest-growing B2B revenue opportunities in telecommunications. The CSPs that will lead are those investing now in the infrastructure that makes autonomous, AI-native networks commercially viable. **Telecom vendors must position themselves as essential enablers of autonomous AI-native CSPs. Value accrues to those whose products and solutions drive real-time operational decisions through enabling intelligence and automation.** *Gartner, 2030 CSP Scenarios in the AI Era Predefine Telco AI Vendor Races' Future, 2026* ![CSP 2030 Scenarios in AI Era](/static/CSP-2030-Scenarios-in-AI-Era.png) Capturing these opportunities is not straightforward. Behind every new revenue stream sits a set of infrastructure challenges that most CSPs are still working through. **The Challenges:** - **Managing old and new technologies together:** Legacy VNFs and modern CNFs must run side by side without disrupting live operations. - **Operating at scale:** Thousands of RAN sites and MEC nodes demand centralized automation to stay manageable. - **Reaching Level 4 Autonomous Networks:** Self-healing, intent-based infrastructure requires the right orchestration foundation first. - **Unlocking Edge Monetization:** Delivering enterprise private 5G, managed compute, and GPU-as-a-Service requires infrastructure that provisions and governs at speed. - **Winning on Sovereign AI:** Procurement is shifting from geo-agnostic to geo-aligned. Jurisdictional independence is now a formal selection criterion. ### How we help ### Solving Every Layer, From Core to Far Edge Each challenge CSPs face today has an infrastructure answer. Kubermatic delivers it through a unified platform, from core to far edge, with GitOps-based automation, zero-trust security, and no vendor lock-in throughout. [Kubermatic Kubernetes Platform](/products/kubermatic-kubernetes-platform/) operates thousands of clusters from a single control plane. Every configuration, policy, and upgrade defined as code and applied automatically via GitOps, making Level 4 Autonomous Networks operationally possible. [Kubermatic KubeOne](/products/kubermatic-kubeone/) manages standalone clusters at RAN sites and distributed locations where minimal footprint, disconnected operation, and Data Sovereignty are non-negotiable. Together, they give CSPs the infrastructure to migrate without disruption, monetize the edge at speed, and win regulated contracts, free from proprietary lock-in. ### Core (Central Command) Runs 5G core functions (AMF, SMF, UPF) and BSS/OSS workloads with full lifecycle automation, zero-packet-loss upgrades, and centralized policy enforcement via GitOps pipelines. ### Edge (Autonomous Regional Operations) Seed Clusters manage MEC workloads autonomously through core outages with no manual intervention. SLMs and DSLMs run locally with zero cloud latency, zero-trust security enforced across every cluster. ### Far Edge (RAN and Enterprise Sites) Extends Kubernetes to RAN sites and enterprise premises, governed centrally without on-site IT expertise. Data Sovereignty guaranteed on bare metal, private cloud, or public cloud, with no proprietary lock-in. ![CSP Vision of the Future Telecom Cloud Infrastructure, Gartner](/static/gartner-csp-vision-telecom-cloud-infrastructure.png) *Source: Gartner, Four Cloud- and AI-Native Capabilities for Telco Cloud Differentiation, 2025* ## Use Cases **5G Core and Cloud Native Network Functions** - Legacy VNFs and modern CNFs run side by side with SR-IOV and DPDK, ensuring carrier-grade throughput. One control plane manages and scales all network functions, cutting new service deployment from weeks to hours. **Level 4 Autonomous Networks and Edge Operations** - Every configuration and policy managed as code via GitOps, deployed automatically across the fleet. Seed Clusters operate autonomously through core outages. When a site degrades, automated remediation triggers without operator input. **Edge Monetization and AI at the Edge** - Provision private 5G, managed edge compute, and GPU-as-a-Service per enterprise customer in minutes. SLMs and DSLMs run locally on GPU-equipped edge nodes for network anomaly detection, predictive maintenance, and real-time QoS. FinOps automation reduces TCO across the fleet. **Data Sovereignty and Zero-Trust Security** - Localized Kubernetes clusters process sensitive data on-premises, fully isolated and auditable. Zero-trust policies and microsegmentation enforced automatically from core to far edge. Multi-Cloud Agnosticism by design: runs on bare metal, private cloud, AWS, Azure, or GCP with no hyperscaler dependency, no proprietary lock-in, built for geo-aligned procurement. [Discover Success Stories](/customers/) ### Outcome ### Operational Efficiency and New Revenue The move from fragmented legacy infrastructure to a unified, open, cloud-native foundation does more than simplify operations. It changes what the network is capable of delivering commercially. ### Lower TCO, faster rollout FinOps automation continuously right-sizes resources, eliminates idle compute, and removes hypervisor licensing costs entirely. Clusters and services deploy in minutes, not weeks. ### Carrier-grade reliability at every layer Zero-trust policies propagate automatically across every cluster without operator involvement. Network SLAs hold, even as the fleet scales. ### The edge becomes a revenue source Private 5G and managed edge compute provisioned per enterprise customer in minutes. Manufacturing, logistics, healthcare, and retail onboard onto sovereign edge infrastructure at speed. ### Sustainability at scale Workload consolidation reduces idle compute across distributed edge nodes, lowering energy consumption and supporting CSP sustainability commitments across the entire fleet. ### Global scale, lean operations Thousands of clusters managed from one dashboard. Headcount stays flat as the network grows. ## Why Kubermatic? ![Proven Leadership](/static/defence-architecture.png) ### Proven Leadership Recognized by Gartner®, Forrester, GigaOM, SPARK Matrix™ and a top contributor to the CNCF. ![Flexibility](/static/defence-why-kubermatic.png) ### Flexibility Supports Bare Metal, vSphere, OpenStack, and all major public clouds (AWS, Azure, GCP). ![Sovereignty](/static/phone-policeman-lock.png) ### Sovereignty Germany-based company offering 100% sovereign infrastructure and secure, private cloud stacks. ![People builds the program](/static/people-builds-the-program.svg) ### Expert Support Implementation, managed services, and 24×7 mission support from Kubernetes experts. --- ## Automate DevOps with Kubernetes - **URL:** https://www.kubermatic.com/solutions/devops/ - **Date:** 2026-07-08 - **Description:** Eliminate manual Ticket-Ops. Discover how Kubermatic delivers frictionless developer self-service and automated cluster provisioning in under 3 minutes. # Automate DevOps with Kubernetes We automate every step of your software development lifecycle. [Talk to an expert](/contact-sales/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Kubermatic for DevOps: Frictionless Self-service ### Situation ### The DevOps Infrastructure Bottleneck Scaling Kubernetes often backfires when manual processes cannot keep pace with cluster growth. DevOps teams find themselves buried in “Ticket-Ops”, hand-provisioning environments, managing snowflake upgrades, and handling compliance cluster by cluster. This fragmentation causes configuration drift that breaks pipelines and stalls releases. When infrastructure depends on constant manual intervention, it becomes a bottleneck instead of an accelerator. Sustainable delivery velocity requires automated, self-service infrastructure at fleet scale. **Traditional ticket-based workflows for cluster provisioning slow down developer velocity, undermining the ability of products to be delivered through DevOps practices and hindering time-to-market for critical initiatives.** *Gartner, Drive DevOps Agility by Scaling Multicluster Kubernetes, September 2025* ### How we help ### The Kubermatic DevOps Stack: From Infrastructure to Interface The DevOps function has two audiences: the platform engineers who keep clusters running, and the developers who ship software on top of them. Kubermatic gives each one a product that takes manual work off their plate. **Kubermatic Kubernetes Platform (KKP)** automates the infrastructure lifecycle, while **Kubermatic Developer Platform (KDP)** provides the self-service interface that developers use to provision resources. To ensure consistency beyond the data center, **Kubermatic KubeOne** extends this same automation model to edge servers and standalone deployments. ### Frictionless Developer Self-service Kubermatic provides DevOps teams with an intuitive self-service portal that works across any infrastructure. Platform teams define approved environments and policies; developers provision and deploy independently, without raising tickets to infrastructure teams. ### Built-in Observability Every managed cluster ships pre-configured with a production-grade monitoring stack (Prometheus, EFK, and Grafana). DevOps teams get deep visibility and alerting from day one, eliminating the need to build separate observability tooling for every cloud. ### Declarative CI/CD Automation We eliminate "it works on my machine" errors by treating infrastructure as code. Using cluster blueprints and GitOps workflows, we ensure identical configurations across every pipeline environment. Automated backups and self-healing clusters run continuously, removing the need for manual intervention or scheduling. ## Use Cases **CI/CD Pipeline Automation on Kubernetes** - **The Mission:** Automate every step of the software delivery lifecycle with consistent, policy-compliant environments at every stage. - **The Application:** KDP provides the self-service interface for CI pipelines to trigger ephemeral environments on demand. KKP provisions these clusters in under 3 minutes and decommissions them automatically, while integrated service accounts eliminate manual credential management. **Self-Service Developer Environments** - **The Mission:** Enable development teams to self-provision compliant Kubernetes environments without platform team involvement, reducing lead times from days to minutes. - **The Application:** Using a multi-tenant model with dedicated roles, developers select a template and receive a fully configured, compliant namespace, complete with pre-integrated monitoring and logging. **Automated Observability and Resilience** - **The Mission:** Eliminate the time spent building and maintaining separate monitoring and backup stacks for every cluster. - **The Application:** KKP ships with a pre-configured stack of Prometheus, Grafana, and EFK. DevOps teams get instant visibility and alerting from day one, while integrated self-healing and automated backups ensure high availability without manual scheduling or intervention. [Discover Success Stories](/customers/) ### Outcome ### Faster Delivery, Fewer Incidents By standardizing on the Kubermatic stack, DevOps teams eliminate the manual overhead that slows delivery cycles and creates on-call fatigue. You ship faster while maintaining stronger operational controls across your entire fleet. ### Cluster Provisioning in Under 3 Minutes Automated provisioning replaces manual cluster setup. Any team, on any approved infrastructure, receives a production-ready Kubernetes environment in minutes — not days of ticket queue time. ### Self-healing Infrastructure Reduces On-call Load KKP’s automated health management detects and remediates common cluster issues without human intervention. On-call engineers focus on novel incidents — not routine remediation that automation should handle. ### Infrastructure as Code from Day One Every cluster configuration, policy, and environment definition lives in Git. Auditable change history, automated rollback, and drift detection ship with the platform — without requiring teams to build their own GitOps tooling. ### Built-in Observability Eliminates Monitoring Setup Prometheus, EFK, and Grafana come pre-configured with every managed cluster. DevOps teams have production-grade monitoring from the first deployment — not after a multi-week monitoring stack build-out. ## Why Kubermatic? ![Proven Leadership](/static/defence-architecture.png) ### Proven Leadership Recognized by Gartner®, Forrester, GigaOM, SPARK Matrix™ and a top contributor to the CNCF. ![Flexibility](/static/defence-why-kubermatic.png) ### Flexibility Supports Bare Metal, vSphere, OpenStack, and all major public clouds (AWS, Azure, GCP). ![Sovereignty](/static/phone-policeman-lock.png) ### Sovereignty Germany-based company offering 100% sovereign infrastructure and secure, private cloud stacks. ![People builds the program](/static/people-builds-the-program.svg) ### Expert Support Implementation, managed services, and 24×7 mission support from Kubernetes experts. --- ## Build Cloud Native AI & ML - **URL:** https://www.kubermatic.com/solutions/build-cloud-native-ai-and-ml/ - **Date:** 2026-07-08 - **Description:** Bridge the gap from data notebooks to global production. Discover how Kubermatic automates the full elastic scaling and lifecycle of your GPU nodes. # Build Cloud Native AI & ML We deliver the infrastructure to ensure consistent AI and ML operations across every environment. [Talk to an expert](/contact-sales/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Production-Grade AI on Any Infrastructure ### Situation ### AI and ML Beyond Traditional Infrastructure Most AI initiatives stall before they ever reach the customer. While data scientists excel at building models in isolated notebook environments, moving those models into production reveals a massive **infrastructure challenge**. Modern AI/ML requires a complex orchestration of high-performance hardware and specialized software that traditional IT isn’t equipped to manage. **The core challenges include**: - **“Works on My Machine”:** Models fail when moving from isolated notebooks to production. - **GPU Inefficiency:** Manual resource management leads to high costs and idle hardware. - **Operational Silos:** Data science teams often end up managing the infrastructure. - **Scaling Bottlenecks:** Static setups cannot meet the elastic demands of training or inference. **Now is the time for organizations to assess whether their data centers and cloud strategies are ready to handle this surge in [AI](https://www.gartner.com/en/information-technology/topics/ai-strategy-for-business) & ML demand. In many cases, they might need to bring AI to where the data is to support this growth.** **By 2028, 95% of new AI deployments will use Kubernetes, up from less than 30% today.** *Gartner, Magic Quadrant for Container Management, 2025* ### How we help ### The AI-Native Infrastructure Platform Kubermatic Kubernetes Platform (KKP) is an official **Kubernetes AI Conformant** platform. It provides a standardized technical blueprint that ensures models trained on one KKP cluster can move to any other conformant cluster without rewriting code. KKP is designed to automate IT operations from the infrastructure to the application, easily operating Kubernetes clusters with consistency from the local development cluster to cloud production deployments. ### GPU Lifecycle Automation KKP automates the full lifecycle of GPU nodes provisioning, health monitoring, and decommissioning—with the same consistency as standard CPU workloads. ### Accelerate Machine Learning Research Data scientists can run reproducible experiments on infrastructure that mirrors production, eliminating the "runs on my laptop, fails in the cloud" problem. Research clusters are provisioned in minutes and decommissioned automatically when experiments are complete. ### Hardware Efficiency KKP utilizes **Dynamic Resource Allocation (DRA)** to eliminate resource fragmentation and the **Advanced GPU Machine Type Selector** to match hardware to workload requirements without over-provisioning. ### Speed Up Inference in Production KKP and the KubeLB AI Gateway enable ML application deployment across cloud, on-premises, and edge environments. The platform automates accelerator node scaling, health monitoring, and model deployment pipelines while using intelligent routing and gang scheduling for reliable, high-performance inference. ## Use Cases **GPU Cluster Management for Data Science Teams** - **The Mission:** Enable multiple teams to share expensive GPU infrastructure without scheduling conflicts or management overhead. - **The Application:** KKP enforces multi-tenancy through isolated GPU quotas and per-project cost attribution. Automated health monitoring detects hardware faults early, preventing corruption of long-running training jobs. **Sovereign Federated Machine Learning** - **The Mission:** Run collaborative ML training across organizations without centralizing sensitive data, maintaining 100% data residency. - **The Application:** As demonstrated in [Project MELLODDY](/blog/melloddy-turning-pharma-competition-into-coopetition/), KKP coordinates training across distributed clusters. Each organization trains on local data; only encrypted model updates aggregate centrally to protect proprietary information. **Production-Ready ML** - **The Mission:** Rapidly transition from manual GPU setups to automated, production-grade ML infrastructure. - **The Application:** [We support your teams](/services/) gain a functioning, GPU-enabled cluster fleet and the operational capability to manage multi-cluster ML workloads independently. [Discover Success Stories](/customers/) ### Outcome ### ML at Production Scale: Faster, Reliably, Anywhere By standardizing on Kubermatic, organizations eliminate the infrastructure friction that stalls model delivery. ### Same Tools from Laptop to Production Official **Kubernetes AI Conformance** provides a standardized technical blueprint that ensures models remain portable across cloud, on-prem, and edge environments without rewriting code. This consistency from local notebooks to global production eliminates configuration drift and environment-specific bugs. ### Reduce Time from Data to Inference Standardized ML pipelines eliminate environment setup overhead. Data scientists focus on models and data, not configuring Kubernetes clusters or debugging infrastructure differences between development and production. ### Elastic Scaling & Cost Optimization KKP scales GPU clusters elastically to meet training demand spikes and scales down automatically to reduce costs when training completes. Inference serving scales horizontally across multiple nodes to handle production traffic without manual capacity planning. ## Why Kubermatic? ![Proven Leadership](/static/defence-architecture.png) ### Proven Leadership Recognized by Gartner®, Forrester, GigaOM, SPARK Matrix™ and a top contributor to the CNCF. ![Flexibility](/static/defence-why-kubermatic.png) ### Flexibility Supports Bare Metal, vSphere, OpenStack, and all major public clouds (AWS, Azure, GCP). ![Sovereignty](/static/phone-policeman-lock.png) ### Sovereignty Germany-based company offering 100% sovereign infrastructure and secure, private cloud stacks. ![People builds the program](/static/people-builds-the-program.svg) ### Expert Support Implementation, managed services, and 24×7 mission support from Kubernetes experts. --- ## Leverage Edge Computing - **URL:** https://www.kubermatic.com/solutions/edge-computing/ - **Date:** 2026-07-08 - **Description:** Automate thousands of Kubernetes nodes seamlessly. Discover how Kubermatic provides resilient, autonomous, and air-gapped operations at the tactical edge. # Leverage Edge Computing We automate thousands of Kubernetes clusters across your chosen edge locations. [Talk to an expert](/contact-sales/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Edge Computing with Kubermatic ### Situation ### Rethinking Infrastructure for the Edge Edge computing demands have outgrown the management tools built for centralized data centers. Thousands of distributed Kubernetes clusters across remote locations, each with different hardware, inconsistent connectivity, and strict latency requirements, cannot be managed with the same runbooks designed for a handful of cloud regions. Without standardization and automation, edge deployments become a security liability. Clusters at remote sites drift from policy baselines. Manual provisioning visits are expensive. Furthermore, as enterprises integrate AI, the demand for fast local decision-making to reduce latency makes reliance on a constant central cloud connection a severe vulnerability for mission-critical workloads. **Enable future expansion of edge computing by focusing on platforms, frameworks and interoperability in the early stages.** *Gartner, Market Guide for Edge Computing, Thomas Bittman et al., June 2025* ### How we help ### Operate Thousands of Edge Clusters from One Control Plane Kubermatic Kubernetes Platform is designed to automate IT operations from the infrastructure to the application — easily operating thousands of Kubernetes clusters across your chosen edge environments. Kubermatic KubeOne manages independent standalone Kubernetes clusters on edge servers, extending the same lifecycle automation model to sites outside the central fleet. Powered by a unique **“Kubernetes-in-Kubernetes”** architecture, we deliver the autonomous edge. By leveraging our Seed Cluster technology, we guarantee that critical local applications and AI inference models continue to run and process data locally even when the connection to the central cloud is severed. ### Global Control Plane We deploy KKP in your central data center or preferred public cloud. This acts as your single pane of glass, establishing global security policies across the entire infrastructure and deploying standardized software to all edge locations simultaneously. ### Industrial Edge (Autonomous Operations) Deployed on local servers within the remote facility, the platform orchestrates Seed Clusters that handle local operations. If the site loses internet connectivity, the Seed Cluster autonomously manages local workloads, ensuring business continuity. ### Device Edge (IoT & AI) The platform pushes containerized AI models directly to specialized hardware, such as assembly line cameras for defect detection (Manufacturing), remote sensors for predictive maintenance (Energy), or patient-monitoring devices (Healthcare), enabling split-second, low-latency processing at the source. ## Use Cases **Air Gapped Edge Operations** - **The Mission:** Manage Kubernetes clusters at edge sites with no internet connectivity, ensuring full lifecycle management, policy enforcement, and workload operations without central cloud reach-back. - **The Application:** KKP’s air-gapped cluster support provisions and manages clusters using pre-staged container images and local registries. Policy updates, Kubernetes upgrades, and application deployments distribute to edge sites during scheduled connectivity windows, with fully autonomous operation between synchronizations. **Bare Metal Edge at Scale** - **The Mission:** Deploy and operate Kubernetes on bare metal servers across hundreds of edge locations, providing cloud-native operations without cloud infrastructure costs. - **The Application:** KKP manages bare metal edge clusters with the same tooling used for cloud-hosted clusters. KubeVirt enables virtual machines and containers to run side by side on the same hardware, supporting legacy workloads that require VM isolation alongside containerized applications. **Edge Computing Accelerator** - **The Mission:** Implement production-grade Kubernetes operations across distributed remote environments in four weeks, including training, tooling, and initial cluster fleet deployment. - **The Application:** Kubermatic’s four-week Edge Computing Accelerator engagement combines training, consultancy, and open source tooling to implement Kubernetes operations across your specific edge environments. Teams leave with a functioning edge cluster management platform and the operational knowledge to extend it independently. [Discover Success Stories](/customers/) ### Outcome ### Scalable Edge Operations at Any Distance By standardizing on Kubermatic Kubernetes Platform, organizations manage thousands of edge nodes with lean platform teams — maintaining governance, security, and operational consistency across every remote location. ### Thousands of Clusters from One Location Centralized fleet management eliminates per-site engineering visits. Provisioning, upgrades, policy enforcement, and health monitoring run from a single control plane — regardless of how many edge sites are in the fleet. ### Zero-Touch Environments Immutable infrastructure and automated provisioning eliminate the configuration drift that creates security gaps. Every new edge site comes up in a known, policy-compliant configuration. ### Resilience Through Autonomy Edge clusters operate independently through connectivity gaps. Air-gapped cluster support ensures workloads continue through internet outages — with state reconciliation running automatically when connectivity resumes. ### Cloud Native Outside the Cloud Bare metal edge servers gain full cloud native operations — managed like cloud machines, with VM and container support running side by side. Organizations capture cloud native benefits without cloud infrastructure dependency. ## Why Kubermatic? ![Proven Leadership](/static/defence-architecture.png) ### Proven Leadership Recognized by Gartner®, Forrester, GigaOM, SPARK Matrix™ and a top contributor to the CNCF. ![Flexibility](/static/defence-why-kubermatic.png) ### Flexibility Supports Bare Metal, vSphere, OpenStack, and all major public clouds (AWS, Azure, GCP). ![Sovereignty](/static/phone-policeman-lock.png) ### Sovereignty Germany-based company offering 100% sovereign infrastructure and secure, private cloud stacks. ![People builds the program](/static/people-builds-the-program.svg) ### Expert Support Implementation, managed services, and 24×7 mission support from Kubernetes experts. --- ## Deploy Hybrid and Multi-cloud Kubernetes - **URL:** https://www.kubermatic.com/solutions/hybrid-multi-cloud/ - **Date:** 2026-07-08 - **Description:** Gain cloud freedom without operational complexity. Discover how Kubermatic manages distributed cluster fleets identically from a single dashboard. # Deploy Hybrid and Multi-cloud Kubernetes We automate hundreds of Kubernetes clusters across any hybrid or multi-cloud environment. [Talk to an expert](/contact-sales/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Multi Cluster Management for Hybrid and Multi-cloud ### Situation ### Managing Clouds Individually Doesn't Scale For IT leaders, the promise of “cloud freedom” has met a hard reality. Managing multiple providers without a unified layer has created a sprawl of duplicated tooling, inconsistent security postures, and specialized silos. Instead of driving innovation, engineering talent is being drained by the friction of incompatible workflows and fragmented compliance. The path to true digital agility requires a shift in perspective: moving beyond managing individual clusters to orchestrating the entire fleet as a single, programmable asset. **By 2027, 90% of organizations will adopt a hybrid cloud strategy, with 75% of large enterprises employing hybrid or multi-cloud setups by 2026 to manage complex infrastructure.** [*Source: Gartner Forecasts Worldwide Public Cloud End-User Spending to Total $723 Billion in 2025*](https://www.gartner.com/en/newsroom/press-releases/2024-11-19-gartner-forecasts-worldwide-public-cloud-end-user-spending-to-total-723-billion-dollars-in-2025) ### How we help ### Standardization, Automation, and Centralized Control Across Every Cloud Kubermatic eliminates multi-cloud complexity by establishing a consistent operational layer based on the declarative Kubernetes API. By abstracting the underlying environment, **Kubermatic Kubernetes Platform (KKP)** provides a universal operational layer. Every environment — on-premises, public cloud, and edge — is managed from a single, centralized control plane. ### Standardization and Automation at Scale KKP replaces snowflake configurations with standardized, automated infrastructure. Platform teams define global standards once, ensuring every cluster, whether in AWS or a local data center, operates with the same reliability, security, and performance. ### Zero-Touch Immutable Infrastructure KKP enables dynamic provisioning with a security-first approach. By leveraging immutable clusters and zero-touch environments, Kubermatic reduces the risk of configuration drift and human error. This creates a global data experience where security is baked into the lifecycle of every asset. ### Reduced Tooling and Compliance Overhead Kubermatic eliminates the need to manage a separate stack and compliance program for every cloud provider. KKP allows scaling across providers with one consistent set of tooling. This unifies operational workflows, reducing licensing costs, and simplifies compliance by providing a single point of audit for the entire global fleet. ## Use Cases **Kubernetes-as-a-Service for Internal Teams** - **The Mission:** Deliver a self-service Kubernetes portal to development teams across multiple cloud providers — without requiring dedicated platform engineers per team. - **The Application:** KKP’s self-service portal enables compliant environment provisioning in under 3 minutes. Developers gain independence while the platform team maintains centralized guardrails. **Application Migration at Scale** - **The Mission:** Speed up large-scale migration of applications onto Kubernetes clusters, removing the need to maintain outdated legacy application infrastructure. - **The Application:** The Kubermatic Application Migration Accelerator (11.5-day engagement) combines training, consultancy, and tooling to execute large migrations systematically. KKP’s fleet management tracks migration waves across all clusters, with automated rollback capability for any workload that fails validation. **Multi-provider Compliance and Security Standardization** - **The Mission:** Enforce consistent security policies, RBAC, and audit controls across AWS, Azure, GCP, and on-premises clusters without maintaining separate compliance programs per provider. - **The Application:** KKP defines and enforces security policies at the platform layer, propagating identical controls to every cluster, regardless of underlying provider. This policy-as-code approach automates audit evidence generation across the entire infrastructure fleet. [Discover Success Stories](/customers/) ### Outcome ### Cloud Freedom Without Operational Complexity By standardizing on [Kubermatic Kubernetes Platform](/products/kubermatic-kubernetes-platform/), organizations gain genuine multi-cloud agility, operating hundreds of clusters across any provider combination with the same tools, workflows, and compliance posture. ### One Toolchain Across Every Cloud Eliminate per-provider operational overhead. Platform teams manage AWS, Azure, GCP, and on-premises clusters identically — reducing tooling costs and cognitive load simultaneously. ### Cluster Deployment in Under 3 Minutes Automated cluster lifecycle management replaces manual provisioning workflows. Self-service portals give teams environment access in minutes — not days of ticket queue time. ### Self-Healing Infrastructure KKP’s automated operations detect and remediate cluster health issues without human intervention — reducing on-call burden and improving overall fleet reliability. ### Centralized Compliance at Scale Security audits cover the platform layer once — not each cloud’s control plane separately. Policy-as-code enforcement generates per-cluster compliance evidence automatically across every provider. ## Why Kubermatic? ![Proven Leadership](/static/defence-architecture.png) ### Proven Leadership Recognized by Gartner®, Forrester, GigaOM, SPARK Matrix™ and a top contributor to the CNCF. ![Flexibility](/static/defence-why-kubermatic.png) ### Flexibility Supports Bare Metal, vSphere, OpenStack, and all major public clouds (AWS, Azure, GCP). ![Sovereignty](/static/phone-policeman-lock.png) ### Sovereignty Germany-based company offering 100% sovereign infrastructure and secure, private cloud stacks. ![People builds the program](/static/people-builds-the-program.svg) ### Expert Support Implementation, managed services, and 24×7 mission support from Kubernetes experts. --- ## Modernize Your IT Infrastructure - **URL:** https://www.kubermatic.com/solutions/modernize-your-infrastructure/ - **Date:** 2026-07-08 - **Description:** Build a unified digital backbone for central and production IT. Discover how Kubermatic simplifies hybrid and multi-cloud infrastructure lifecycles. # Modernize Your IT Infrastructure We build the unified digital backbone for your central and production IT. [Talk to an expert](/contact-sales/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Kubermatic IT Modernization: One Platform. Total Control. ### Situation ### The High Cost of Digital Stagnation Legacy systems consume 70% of IT budgets, leaving little for innovation. To survive constant market disruption, organizations must shift from siloed utilities to a programmable, cloud-native backbone that unifies operations from the core data center to the edge. **By 2027, more than 75% of organizations will adopt a "cloud-native first" strategy as the primary driver for digital agility, achieving a 50% increase in operational efficiency compared to traditional infrastructure models.** *— Gartner* Cloud-native modernization delivers what legacy systems cannot: - Improved resource utilization and reduced overall IT spend - Facilitated application upgrades and maintenance - Shorter software development cycles - Hybrid and multi-cloud enablement **Connect or Get Disconnected** The “one-size-fits-all” cloud is a myth. Success requires a unified foundation capable of integrating AI, Big Data, and IoT without architectural rework. ### How we help ### The Unified Cloud Native Backbone Kubermatic eliminates the friction of fragmented IT by establishing a single, API-first foundation across your entire enterprise. Our platform acts as a universal control plane, unifying central IT and production under one streamlined process. We transform complex infrastructure into a programmable asset, enabling full lifecycle management from a single pane of glass. ### Future-Proof by Design Our end-to-end solution simplifies your journey to cloud native. We unify edge and cloud environments to provide frictionless **Day 2 operations**, allowing you to innovate in well-ordered steps. By integrating new solutions as they emerge, we ensure your organization stays ahead of the curve rather than reacting to it. ### Exploit Existing Systems Modernization shouldn't mean discarding your current technology stack. Every asset is valuable and your existing tech stack should be leveraged to its full potential. Kubermatic enables you to run cutting-edge projects and legacy workloads side-by-side, allowing you to modernize without unnecessary costs. ### Accelerate Now Complex projects require excellence to succeed. Our team makes you DRIFT — Do It Right the First Time. From initial assessment to production-ready cloud native infrastructure, Kubermatic's professional services accelerate every phase of your modernization journey. ## Use Cases **One Platform Across Central and Production IT** - **The Mission:** Align the entire organization on a single operational process, eliminating tool sprawl and siloed environments. - **The Application:** Kubermatic (KKP) provides a unified control plane for data centers and public clouds. Define policies once and enforce them fleet-wide, from the core to the production edge, using a single declarative API. New solutions integrate without disrupting workloads running in parallel. **Risk-Free Legacy Workload Modernization** - **The Mission:** Modernize legacy infrastructure incrementally, preserving existing hardware investments while adopting cloud native speed. - **The Application:** KKP enables new projects and legacy workloads to run side by side during transition periods. KubeOne automates cluster lifecycle management on existing bare metal hardware, delivering cloud native operations without replacing physical infrastructure. **Industry 4.0 & AI Readiness** - **The Mission:** Build the foundation for autonomous robotics, IoT, and AI demanding real-time, distributed, and scalable compute. - **The Application:** Kubermatic unifies edge and cloud environments under a single operational model. IoT devices stream data to edge Kubernetes clusters for local processing; AI models deploy to central infrastructure for training. Every technology integration runs on the same governed platform. [Discover Success Stories](/customers/) ### Outcome ### A Unified, Future-Ready Digital Backbone By standardizing on the Kubermatic Kubernetes Platform, organizations replace fragmented IT landscapes with a single, coherent infrastructure. You gain a foundation capable of absorbing AI, Edge, and Industry 4.0 workloads without architectural rework, ensuring your IT evolves as fast as the market. ### Improved Resource Utilization Cloud native containerization delivers higher workload density on the same hardware. Legacy VMs running at 15–30% utilization are replaced by containers sharing compute at 70%+, reducing infrastructure footprint and cost. ### Shorter Software Development Cycles Standardized environments from development to production eliminate the ‘works on my machine’ problem. Teams deploy faster, with higher confidence, because every environment behaves identically across the pipeline. ### Hybrid and Multi-cloud Enablement KKP manages clusters across on-premises hardware, private cloud, and public cloud providers from a single control plane — giving organizations genuine cloud agility without rebuilding infrastructure for each environment. ### Reduced Overall IT Spend Consolidating on one platform eliminates duplicated tooling, licensing, and operational overhead. Frictionless Day 2 operations mean fewer incidents, faster recovery, and less time spent on manual cluster management. ## Why Kubermatic? ![Proven Leadership](/static/defence-architecture.png) ### Proven Leadership Recognized by Gartner®, Forrester, GigaOM, SPARK Matrix™ and a top contributor to the CNCF. ![Flexibility](/static/defence-why-kubermatic.png) ### Flexibility Supports Bare Metal, vSphere, OpenStack, and all major public clouds (AWS, Azure, GCP). ![Sovereignty](/static/phone-policeman-lock.png) ### Sovereignty Germany-based company offering 100% sovereign infrastructure and secure, private cloud stacks. ![People builds the program](/static/people-builds-the-program.svg) ### Expert Support Implementation, managed services, and 24×7 mission support from Kubernetes experts. --- ## Public Sector & Government Solution - **URL:** https://www.kubermatic.com/solutions/public-sector-and-government/ - **Date:** 2026-07-08 - **Description:** Build sovereign digital public infrastructure. Discover how Kubermatic ensures data residency and automated compliance across air-gapped systems. # Public Sector Solution We deliver sovereign infrastructure for efficient, resilient digital government. [Talk to an expert](/contact-sales/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Sovereign Infrastructure for Digital Transformation ### Situation ### The Push for Operational Efficiency and Sovereign AI Public sector organizations are under pressure to deliver more with less. **The mandate for CIOs has shifted: Operational efficiency has officially surpassed the "citizen experience" as the number one driver for digital investment.** *2025 Gartner Transition to Digital Government Survey* Governments must improve efficiency amid shrinking budgets, workforce shortages, and geopolitical uncertainty. To meet these demands, agencies are adopting Agile, DevOps, automation, and Generative AI. However, digital transformation requires more than modernizing legacy systems. **The Challenge:** Without a common platform, modernization creates new barriers: - **Siloed Modernization:** Upgrading individual applications without a common platform creates fragmented data, inconsistent operations, and unnecessary complexity. - **The Sovereignty Imperative:** The current geopolitical instability means EMEA governments cannot rely on US-based hyperscalers for this transformation. Critical data must remain strictly sovereign. - **The Legacy Tax:** Proprietary virtualization platforms (such as VMware) drain the exact budget needed to fund new AI and automation initiatives. Gartner further points out the gaps that the public sector faces: ![Top Government Trends in EMEA for 2025, Gartner](/static/top-government-trends-in-emea-for-2025-gartner.png) *Source: Top Government Trends in EMEA for 2025, Gartner* ### How we help ### The Kubermatic Platform Engine Each challenge the public sector faces today has an infrastructure answer. Kubermatic provides a single, hardware-agnostic platform that enables governments to modernize infrastructure, automate operations, and deploy AI while **maintaining digital sovereignty**. Kubermatic **eliminates siloed modernization** by implementing a unified management plane. Through this control center, governments can standardize Agile and DevOps operations across federal data centers, regional municipal hubs, and local edge agencies. Powered by a unique “Kubernetes-in-Kubernetes” architecture, the platform allows government IT to **escape proprietary virtualization platforms** such as VMware, freeing budget for AI and modernization initiatives. Built on **open-source, perpetual software**, it provides a long-term foundation. ### The Resilient Public Sector Architecture ### Sovereign Command & Control (Federal/Central Gov Data Center) We deploy the Kubermatic Kubernetes Platform on your secure, air-gapped bare metal or sovereign private cloud. This serves as your centralized command center, breaking down data silos and enforcing Zero-Trust compliance across the entire digital public sector. ### Regional Resiliency Tier (Regional & Municipal Hubs) Deployed in regional facilities, the platform orchestrates **Autonomous Seed Clusters** that maintain full control plane functions locally. If wide-area network connectivity drops, regional agencies continue to function autonomously, ensuring continuity of operations (COOP). ### Tactical Edge (Local Agencies & Smart Cities) The platform securely pushes containerized applications, digital identity tools, and GenAI models directly to branch offices and emergency response networks. ## Use Cases **Drive Operational Efficiency & DevOps at Scale** - Government IT teams must support growing digital services with limited budgets and staffing. - Kubermatic automates the lifecycle management of thousands of Kubernetes clusters through a unified control plane, reducing manual operations and enabling a small central team to manage infrastructure at scale. **Modernize Legacy Infrastructure and Fund Innovation** - Many agencies remain dependent on costly virtualization platforms and siloed legacy applications. - [Kubermatic Virtualization](/products/kubermatic-virtualization/) (built on KubeVirt) enables virtual machines and containers to run on the same platform, reducing infrastructure costs while creating a path to modernization and AI adoption. **Ensure Sovereignty and Data Residency** - Kubermatic runs on **sovereign infrastructure and open-source technology**, enabling agencies to maintain control over data residency, operations, and technology choices without dependence on foreign hyperscalers. [Discover Success Stories](/customers/) ### Outcome ### True Transformation and Resilient Services By standardizing on the **Kubermatic Kubernetes Platform**, government agencies move beyond superficial modernization to achieve a highly efficient, sovereign digital infrastructure. ### Operational Efficiency at Scale Radically lower IT overhead. Unify VMs and containers via KubeV, retire legacy hypervisor taxes, and manage massive state-wide deployments from a single dashboard. ### Absolute Sovereign Compliance Meet the strictest national security and data-residency mandates. Keep sensitive citizen data within controlled borders while maintaining the rapid deployment capabilities of a public cloud. ### Resilient Service Delivery Ensure continuity of operations at the regional and municipal levels. Autonomous edge architecture ensures that central network failures do not disrupt local emergency or public services. ### Governed AI Adoption Provide a secure foundation for Generative AI and automation initiatives. Deploy AI workloads on infrastructure that remains auditable, compliant, and under government control. ## Why Kubermatic? ![Proven Leadership](/static/defence-architecture.png) ### Proven Leadership Recognized by Gartner®, Forrester, GigaOM, SPARK Matrix™ and a top contributor to the CNCF. ![Flexibility](/static/defence-why-kubermatic.png) ### Flexibility Supports Bare Metal, vSphere, OpenStack, and all major public clouds (AWS, Azure, GCP). ![Sovereignty](/static/phone-policeman-lock.png) ### Sovereignty Germany-based company offering 100% sovereign infrastructure and secure, private cloud stacks. ![People builds the program](/static/people-builds-the-program.svg) ### Expert Support Implementation, managed services, and 24×7 mission support from Kubernetes experts. --- ## Defence Solution - **URL:** https://www.kubermatic.com/solutions/defence/ - **Date:** 2026-07-08 - **Description:** Discover how Kubermatic powers Software Defined Defence with autonomous, air-gapped Kubernetes fleets engineered for the tactical battlefield edge. # Defence Solution We build infrastructure for modern defence challenges. [Talk to an expert](/contact-sales/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Kubermatic Software Defined Defence (SDD): Winning the AI-Driven Battlefront ### Situation ### The AI Shockwave and the Sovereign Cloud Gap Modern defense operations are facing an **AI Shockwave**. In highly contested environments, advanced electronic warfare (EW) and peer-level adversaries are causing rapid attrition of traditional systems. To survive, defense organizations are accelerating the deployment of low-cost, autonomous platforms driven by edge AI. However, traditional monolithic and centralized IT infrastructures cannot support real-time AI at the tactical edge. **By 2029, 75% of defense AI strategies will require a total review to address critical gaps in sovereign cloud infrastructure and data-residency.** *Gartner, Predicts 2026: Defense Organizations Bracing for AI Shockwaves, Jay Phipps, Ripley Hunter, Michael McFerron* **The Connectivity Crisis:** [The UK Ministry of Defence](https://www.gov.uk/government/publications/cloud-strategic-roadmap-for-defence/cloud-strategic-roadmap-for-defence) asserts that modern strategy demands **change at the edge.** Operators must process field data in real-time without constant connectivity. Zero-bandwidth, **DDIL (Denied, Degraded, Intermittent, and Limited)** environments are now baseline tactical assumptions, making reliance on a central cloud "reach-back" a severe vulnerability. ![The change at the edge — local cloud edge computing capability enables quick decision making and data manipulation](/static/software-defined-defence.jpg) ### How we help ### The Kubermatic Platform Engine and DDIL by Design Software Defined Defence (SDD) is the operational concept, but the **Kubermatic Kubernetes Platform** (KKP) is the technical engine that makes it a reality. Powered by a unique **“Kubernetes-in-Kubernetes”** architecture, Kubermatic delivers **DDIL by Design**. KKP provides a complete, hardware-agnostic battlefield stack engineered specifically to ensure operational continuity across intermittently connected environments. KKP manages fleet orchestration, automates traffic routing, and enforces security policies without human intervention. ### The Resilient Architecture: Core, Fog, and Edge ### Core (Sovereign Command) We deploy the Kubermatic Kubernetes Platform on your secure, sovereign private cloud or air-gapped bare metal. This acts as your "AI Factory," where models are trained, governed, and cryptographically secured against tampering before field deployment. ### Fog (Autonomous Resilience) Deployed in mobile command centers, the platform orchestrates **Seed Clusters** that maintain full control plane functions locally. This is the heart of "DDIL by Design": if communications are jammed, the Fog continues to orchestrate local sensors and weapons systems autonomously. When the link returns, local states and global traffic are instantly synchronized. ### Edge (Tactical AI) The **Kubermatic Kubernetes Platform** pushes containerized AI inference models directly to drones, sensors, and soldier-worn systems, allowing over-the-air updates to counter evolving adversarial tactics in real time. ![Architecture design](/static/architecture-design.png) ## Use Cases **Mobile Command Centers in DDIL Environments** - **The Mission:** Maintaining command and control (C2) when adversaries actively jam communications. - **The Application:** Utilizing the platform’s Seed Cluster architecture, forward operating bases run fully autonomous environments. Applications remain completely operational under zero-bandwidth conditions, autonomously handling local load balancing until global reach-back is re-established. **Preemptive Cybersecurity & Secure ModelOps** - **The Mission:** Defending against AI-driven advanced persistent threats (APTs) targeting mission-critical systems and preventing deepfake impersonation. - **The Application:** The Kubermatic Kubernetes Platform acts as the secure pipeline for deploying updated AI models to the field. By enforcing Zero-Trust policies and automated secret management, the platform ensures only cryptographically verified, unaltered AI workloads execute at the edge. **Intelligence, Surveillance, and Reconnaissance (ISR) at the Edge** - **The Mission:** Processing massive streams of sensor data in real-time without overwhelming limited bandwidth. - **The Application:** Kubermatic deploys lightweight AI inference workloads directly onto unmanned aerial systems (UAS). Data is processed locally for immediate detect-classify-track capabilities, transmitting only highly compressed, actionable intelligence back to command. [Discover Success Stories](/customers/) ### Outcome ### Information Superiority and Operational Freedom By standardizing on the **Kubermatic Kubernetes Platform**, defense organizations replace legacy technical debt with an agile, preemptive, and data-driven force structure. ### Mission Continuity in DDIL Achieve **100% operational uptime** at the edge during communications-denied windows. Autonomous platforms complete their objectives without human-in-the-loop networking dependencies. ### Preemptive Cybersecurity Counter AI-driven malware with a **Zero-Trust architecture**. The platform protects mission-critical workloads and AI models from interception, manipulation, or unauthorized access. ### Global Scalability with 1 FTE Leverage Kubermatic’s Kubernetes-in-Kubernetes density to manage thousands of globally distributed clusters across land, air, and sea from **a single dashboard**. ### Absolute Sovereign Compliance Meet the strictest **national security** and **data-residency mandates**. Keep sensitive intelligence within controlled, sovereign borders while maintaining the rapid deployment capabilities of a true cloud-native ecosystem. ![Michi Nagel](/static/Michi-Nagel-360x360.png) ### Ready to deploy Software Defined Defence? Michi Nagel Partner Manager  |  Kubermatic #### Let's connect [![Call](/images/call-icon.svg) +49 178 8828485](tel:+491788828485) [![Book a meeting](/images/calendar-icon.svg) Book a meeting](https://meetings.hubspot.com/michael775/30) ## Why Kubermatic? ![Proven Leadership](/static/defence-architecture.png) ### Proven Leadership Recognized by Gartner®, Forrester, GigaOM, SPARK Matrix™ and a top contributor to the CNCF. ![Flexibility](/static/defence-why-kubermatic.png) ### Flexibility Supports Bare Metal, vSphere, OpenStack, and all major public clouds (AWS, Azure, GCP). ![Sovereignty](/static/phone-policeman-lock.png) ### Sovereignty Germany-based company offering 100% sovereign infrastructure and secure, private cloud stacks. ![People builds the program](/static/people-builds-the-program.svg) ### Expert Support Implementation, managed services, and 24×7 mission support from Kubernetes experts. --- ## Automotive & Manufacturing Solution - **URL:** https://www.kubermatic.com/solutions/automotive-and-manufacturing/ - **Date:** 2026-07-08 - **Description:** Discover how Kubermatic unifies IT and OT on a single platform, eliminating costly hypervisor licenses. # Manufacturing Solution We unify IT and OT to build the autonomous, AI-driven factory. [Talk to an expert](/contact-sales/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Unifying IT/OT for the AI-Driven Factory ### Situation ### The AI Surge vs. Legacy IT/OT Realities The manufacturing sector is entering a massive technology supercycle. **CEOs are demanding digital initiatives that drastically improve employee productivity (79%) and reduce costs (68%).** *Gartner's 2026 CIO Agenda: Manufacturing Insights* To deliver these outcomes, 86% of manufacturing enterprises are surging investments in AI and Generative AI, while 82% are prioritizing cybersecurity upgrades. ![Gartner, Strategic IT Cost Optimization for Manufacturing CIOs, 18 June 2025](/static/gartner-strategic-it-cost-optimization-for-manufacturing-cios.png) *Source: Gartner, Strategic IT Cost Optimization for Manufacturing CIOs, 18 June 2025* **The Challenge:** CIOs cannot execute this AI and security mandate on legacy infrastructure. - **The IT/OT Divide:** Shop floors are restricted by “piecemeal integrations” between modern IT and legacy Operational Technology (OT). This lack of a cohesive digital thread blocks data visibility. - **The Cost of Legacy Virtualization:** Factories are burdened by expensive, proprietary hypervisor licenses required to run legacy Windows-based applications. - **The Fragile Industrial Edge:** Pushing high-performance AI models to the assembly line requires local processing. Relying on continuous connectivity to a central cloud introduces unacceptable latency and risks catastrophic production halts if the network drops. ### How we help ### The Kubermatic Platform Engine and the Autonomous Edge Kubermatic bridges the gap between the corporate data center and the factory floor. The **Kubermatic Kubernetes Platform** acts as the technical engine for the industrial edge, providing a unified, hardware-agnostic foundation that manages both modern AI containers and legacy virtual machines across thousands of global plants. Powered by a unique **“Kubernetes-in-Kubernetes”** architecture, we deliver the autonomous factory. By leveraging our **Seed Cluster** technology, we guarantee that critical shop-floor applications continue to run and process AI locally even when the connection to the central cloud is severed. ### The Resilient Industrial Architecture ### Global Control Plane We deploy the Kubermatic Kubernetes Platform in your central data center or preferred public cloud. This acts as your single pane of glass, establishing global cybersecurity policies across the entire digital thread and deploying standardized software to all plants simultaneously. ### Industrial Edge (Autonomous Shop Floor) Deployed on industrial servers within the plant, the platform orchestrates **Seed Clusters** that handle local IT/OT operations. If the plant loses internet connectivity, the Seed Cluster autonomously manages local workloads, ensuring the production line never stops. ### Device Edge (Industrial IoT & AI) The platform pushes containerized AI models and lightweight workloads directly to assembly line sensors, robotic arms, and automated guided vehicles (AGVs) for real-time, low-latency processing. ## Use Cases **Legacy IT/OT Convergence & Cost Reduction** - **The Mission:** Modernizing the factory floor and reducing infrastructure overhead without refactoring decades-old operational software. - **The Application:** Using **Kubermatic Virtualization (KubeV)**, legacy Windows-based OT applications and traditional VMs are run natively alongside modern containers within the same Kubernetes platform. This allows manufacturers to retire expensive legacy hypervisor licenses (like VMware), directly answering the CEO mandate for cost reduction. **Deploying Edge AI for Production Quality** - **The Mission:** Executing the CIO’s AI strategy by running computer vision and GenAI models on the assembly line to detect product defects in real-time. - **The Application:** The Kubermatic Kubernetes Platform acts as the centralized ModelOps pipeline. It seamlessly pushes updated machine learning models to the factory floor, processing massive amounts of visual data locally for millisecond decision-making without saturating enterprise bandwidth. **Autonomous Shop Floor Operations (Resilience)** - **The Mission:** Ensuring manufacturing execution systems (MES) and local databases remain operational during network outages to prevent costly production halts. - **The Application:** Utilizing the platform’s Seed Cluster architecture, individual factories run fully autonomous edge environments. If the WAN connection to the central enterprise cloud drops, local orchestration continues uninterrupted, synchronizing data securely only when the connection is restored. [Discover Success Stories](/customers/) ### Outcome ### Productivity, Cost Efficiency, and Security By standardizing on the **Kubermatic Kubernetes Platform**, industrial organizations eliminate the friction between IT and the shop floor, turning legacy factories into agile innovation hubs. ### Radical Cost Reduction Break down silos by unifying VMs and containers. KubeV allows you to modernize at your own pace, drastically reducing licensing costs from legacy virtualization vendors. ### Zero-Downtime Productivity Achieve continuous operations at the factory level. Autonomous edge architecture ensures that network failures never translate into costly production line stoppages. ### Enterprise-Grade Cybersecurity Answer the top IT funding priority by replacing fragmented integrations with a unified, Zero-Trust Kubernetes architecture that secures the entire digital thread from the core data center to the OT edge. ### Global Scalability with 1 FTE Leverage unparalleled architectural density to manage thousands of distributed factory clusters worldwide from a single, centralized dashboard. ![Michi Nagel](/static/Michi-Nagel-360x360.png) ### Ready to modernize Your factory infrastructure? Michi Nagel Partner Manager  |  Kubermatic #### Let's connect [![Call](/images/call-icon.svg) +49 178 8828485](tel:+491788828485) [![Book a meeting](/images/calendar-icon.svg) Book a meeting](https://meetings.hubspot.com/michael775/30) ## Why Kubermatic? ![Proven Leadership](/static/defence-architecture.png) ### Proven Leadership Recognized by Gartner®, Forrester, GigaOM, SPARK Matrix™ and a top contributor to the CNCF. ![Flexibility](/static/defence-why-kubermatic.png) ### Flexibility Supports Bare Metal, vSphere, OpenStack, and all major public clouds (AWS, Azure, GCP). ![Sovereignty](/static/phone-policeman-lock.png) ### Sovereignty Germany-based company offering 100% sovereign infrastructure and secure, private cloud stacks. ![People builds the program](/static/people-builds-the-program.svg) ### Expert Support Implementation, managed services, and 24×7 mission support from Kubernetes experts. --- ## Mario Fahlandt Appointed to CNCF Technical Oversight Committee - **URL:** https://www.kubermatic.com/blog/2026-05-mario-fahlandt-cncf-toc/ - **Date:** 2026-05-21 - **Description:** Kubermatic architect Mario Fahlandt has been appointed to the CNCF Technical Oversight Committee by the Governing Board. The TOC guides the technical direction of over 200 cloud-native projects. - **Categories:** Community - **Tags:** Kubernetes - **Authors:** Abubakar Siddiq Ango **Kubermatic's Customer Delivery Architect joins the body that governs over 200 cloud-native projects** Mario Fahlandt, Customer Delivery Architect at Kubermatic, has been appointed to the Cloud Native Computing Foundation (CNCF) Technical Oversight Committee (TOC) by the Governing Board. His two-year term began on May 12, 2026. ## What is the CNCF TOC? The Technical Oversight Committee is the technical governing body of the CNCF. It oversees the Foundation's entire project portfolio — currently over 200 projects including Kubernetes, Prometheus, and Envoy — and defines technical standards for the cloud-native ecosystem. Over 300,000 contributors and 700 member organizations worldwide form the CNCF community. ## About Mario Fahlandt At Kubermatic, Fahlandt works on enterprise-scale Kubernetes platforms as Customer Delivery Architect. He co-chairs Kubernetes SIG ContribEx and, with Yuan Tang, the AI Conformance Subproject, which established a certification standard for AI workloads on Kubernetes. Prior to his TOC appointment, Fahlandt served as Co-Chair of the CNCF TAG Operational Resilience. He is also a CNCF Ambassador, Google Developer Expert for Cloud, Google Cloud Champion Innovator, and Arm Ambassador. ## Kubermatic in the CNCF Ecosystem Kubermatic actively contributes to Kubernetes, KubeVirt, and Cluster API, and builds its products directly on CNCF projects. The Kubermatic Kubernetes Platform (KKP) is an enterprise solution for managing Kubernetes fleets across multi-cloud and edge environments. ## The 2026 TOC Cohort The 2026 cohort also includes Ahmed Bebars, Brandt Keller, Joseph Sandoval, Kevin Wang, Mauricio Salatino, Katie Gamanji, and Ricardo Aravena. Karena Angell serves as Chair. --- ## Kubermatic and Dell Technologies Announce Strategic Partnership to Accelerate Cloud-Native Infrastructure - **URL:** https://www.kubermatic.com/blog/kubermatic-dell-technologies-strategic-partnership/ - **Date:** 2026-06-02 - **Description:** Kubermatic and Dell Technologies partner to deliver a validated, sovereign-ready Kubernetes stack for AI infrastructure, VMware modernization, and enterprise scale. - **Categories:** Company - **Tags:** Announcements - **Authors:** Romain Bauer Enterprises are modernizing at an unprecedented pace. The shift toward cloud-native infrastructure, the rise of intensive AI workloads, and the legal mandate for full data sovereignty are forcing organizations to rethink their IT foundations. To meet this demand, Kubermatic and Dell Technologies are joining forces to deliver a unified, sovereign-ready infrastructure stack. ## Control without compromise Kubermatic and Dell Technologies bring complementary strengths to the table: open-source Kubernetes expertise on one side, enterprise-grade hardware on the other. As a Dell Partner, Kubermatic now pairs its platform directly with Dell's infrastructure portfolio, giving organizations a complete, validated stack that meets the region's strict requirements for data sovereignty and operational control. ## Solving Global Infrastructure Priorities This partnership is engineered to solve the most pressing challenges facing CTOs and Platform Engineers worldwide: **Virtualization modernization:** Organizations are actively reassessing their virtualization strategies. The appetite for open, flexible alternatives has never been stronger and the window to act is now. **AI infrastructure readiness:** AI workloads are moving from pilot to production faster than most infrastructure roadmaps anticipated. The compute, storage, and orchestration demands that come with them require a purpose-built foundation. **Data sovereignty:** For enterprises operating in Europe, keeping data and operations within defined borders is not optional. It is a baseline requirement that every infrastructure decision must satisfy. **Operational efficiency:** As environments grow more complex, the ability to manage infrastructure consistently and at scale without proportionally growing the team has become a strategic priority. ## Technical Excellence: Where Automation Meets Enterprise Hardware Rather than patching existing limitations, this partnership is built around a clean architectural approach: Kubermatic's Kubernetes platform as the orchestration and automation layer, running on Dell Technologies infrastructure that enterprises already trust for performance and reliability. The [Kubermatic Kubernetes Platform](/products/kubermatic-kubernetes-platform/) provides the engine for full cluster lifecycle automation from provisioning and autoscaling to updates and multi-region management. [Kubermatic Virtualization](/products/kubermatic-virtualization/) extends this capability by enabling organizations to run virtual machines alongside containerized workloads on the same Kubernetes-native platform, creating a seamless path from traditional virtualization to cloud-native environments without operational disruption. Dell's hardware portfolio provides the foundation: validated, enterprise-grade compute and storage that eliminates the gap between cloud-native software ambitions and real-world infrastructure requirements. > "Our partnership with Dell Technologies enables enterprises to embrace cloud-native infrastructure on proven, enterprise-grade hardware. Together, we're helping organizations in Europe to modernize their VMware environments and to build the AI infrastructure of tomorrow, all while maintaining full data sovereignty." > > **Julian Hansert, Co-founder & COO at Kubermatic** ## About Dell Technologies Dell Technologies is a global technology leader helping organizations and individuals build their digital future. With a portfolio spanning infrastructure, cloud, and edge solutions, Dell serves customers in more than 180 countries. Dell's enterprise hardware portfolio, including PowerEdge servers and PowerStore storage, is trusted by organizations worldwide as the foundation for mission-critical workloads. --- ## Das vergessene Fundament der KI-Transformation - **URL:** https://www.kubermatic.com/resources/das-vergessene-fundament-der-ki-transformation/ - **Date:** 2026-05-08 - **Description:** Sebastian Scheele, CEO und Co-Founder von Kubermatic, spricht darüber, warum der Engpass bei KI-Projekten nicht die Technologie ist, sondern Betrieb, Security-Basics und Disziplin. # Das vergessene Fundament der KI-Transformation ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ![](/static/pdcst-cover-above-c-level-img_hu_60d3fb069f4a01d.jpg) Podcast ## Das vergessene Fundament der KI-Transformation KI ist in den Unternehmen angekommen: Hardware ist verfügbar, Modelle sind reif. Trotzdem bleiben viele KI-Projekte im Proof-of-Concept stecken. In dieser Episode von Above Sea Level spricht Sebastian Scheele, CEO und Co-Founder von Kubermatic, darüber, warum der Engpass nicht die Technologie ist, sondern Betrieb, Security‑Basics und Disziplin. [Listen](https://above-c-level.simplecast.com/episodes/das-vergessene-fundament-der-ki-transformation) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Introducing KubeLB 1.4: A New Dashboard, Air-Gap Ready Deployments, and Hardened Multi-Tenancy - **URL:** https://www.kubermatic.com/blog/introducing-kubelb-1-4-a-new-dashboard-air-gap-ready-deployments-and-hardened-multi-tenancy/ - **Date:** 2026-04-30 - **Description:** KubeLB 1.4 is live. Explore all the new features, including the KubeLB dashboard, Network Policies, Offline Deployment Support, and more! - **Categories:** Products - **Tags:** KubeLB - **Authors:** Waleed Malik KubeLB 1.4 has officially launched, and we are excited to share its release! This version introduces the most significant improvement to the operator experience yet: an entirely new web-based Dashboard. This update also brings robust support for air-gapped and offline deployments, and a set of multi-tenant security controls (Network Policies, Upstream TLS) that make it easier than ever to run KubeLB in regulated and restricted environments. ## Release Highlights of KubeLB 1.4 ### KubeLB Dashboard Until today, KubeLB's power was available only through kubectl CLI and CRDs. KubeLB 1.4 changes that with a brand-new web Dashboard, purpose-built for day-2 operations across a multi-tenant fleet. Browse your tenants, LoadBalancers, Routes, WAF policies etc and get a detailed overview of health, traffic flow, and configuration without ever leaving the browser. OIDC authentication plugs cleanly into any corporate identity provider, and an optional out-of-cluster kubeconfig lets you run the dashboard outside the management cluster if that fits your network model better. The edition is auto-detected at runtime, so no separate installations or manual handling are required. Learn more at the [KubeLB Dashboard repository](https://github.com/kubermatic/kubelb-dashboard) and the [KubeLB Dashboard documentation](https://docs.kubermatic.com/kubelb/v1.4/dashboard). ### Air-Gap / Offline Deployment Support Many of our enterprise users run KubeLB in regulated or sensitive environments where the management cluster has no direct internet access. KubeLB 1.4 makes air-gapped deployments a fully supported, first-class path. Every release now publishes the complete list of container images and Helm charts shipped by KubeLB, including bundled addons, as a release artifact. Customers can mirror that list into an internal registry once and scan it through their own supply chain. All artifacts (container images and charts) are pinned to their specific SHA versions for security and immutability. Learn more in the [Air-Gap Installation](https://docs.kubermatic.com/kubelb/v1.4/tutorials/airgap-installation). ### Network Policies for Tenant Isolation As KubeLB grows into the de-facto multi-tenant load balancer on Kubernetes, stronger tenant isolation has become a frequent ask from platform teams. For even harder tenant separation and to avoid issues like noisy neighbours; KubeLB now ships first-class Kubernetes NetworkPolicies for tenant isolation out of the box. Operators get safe defaults from day one, while still being able to enable, disable, or layer additional policies at both Global and Tenant level. This works hand-in-hand with KubeLB's existing namespace-per-tenant isolation model, giving you L3/L4 network-level guarantees to complement the API-level controls you already have. Learn more in the [Network Policies](https://docs.kubermatic.com/kubelb/v1.4/tutorials/security/network-policies/). ### Web Application Firewall has been promoted to Beta Feature This release also brings targeted improvements to both the Community Edition (CE) and Enterprise Edition (EE). ## KubeLB Enterprise Edition (EE) Features - **KubeLB Dashboard**: Web UI for browsing tenants, LoadBalancers, Routes, and WAF policies across the fleet. - **Air-Gap Deployment Support**: Full offline deployment with published image/chart manifests and mirror-registry support. - **Network Policies for Tenant Isolation**: First-class Kubernetes NetworkPolicies configurable at Global or Tenant level. - **Web Application Firewall (WAF) promoted to Beta**: The WAF feature introduced in v1.3 as Alpha is now Beta. - **Upstream TLS for Backend Connections**: TLS connection management and re-encryption support has been added to KubeLB. - **Configurable Load Balancing Policy**: Pick `RoundRobin`, `LeastRequest`, or `Random` per LoadBalancer, per tenant, or globally. ## KubeLB Community Edition (CE) Features - **Dual-stack and IPv6-only support improvements** - **Client-IP preservation enhancements** - **Proxy Protocol v2 support**: Client-IP preservation for TCP LoadBalancer services. - **Gateway API CRDs upgraded to latest v1.5.1**. - **Per-Tenant Envoy Proxy Sizing**: Ability to configure replicas per tenant or globally. - **PodMonitor support for Envoy Proxy**. - **Built on Go 1.26.2** with a broad set of security and stability fixes. ## Get Started with KubeLB 1.4 Today! - **Check out the release on** [GitHub](https://github.com/kubermatic/kubelb) and give us a star! ;) - **Read the docs**: Go through the detailed [release notes](https://docs.kubermatic.com/kubelb/v1.4/release-notes/) and [documentation](https://docs.kubermatic.com/kubelb/v1.4/) for specific configuration guides. We encourage all users to upgrade to v1.4 and explore the new capabilities that KubeLB has to offer. A huge thank you to our entire community, our customers, and the dedicated contributors who helped shape this incredible release. We can't wait to see what you build with KubeLB 1.4! --- ## What Is KubeVirt, and How Does It Fit Into Kubermatic Virtualization? - **URL:** https://www.kubermatic.com/blog/what-is-kubevirt-and-how-does-it-fit-into-kubermatic-virtualization/ - **Date:** 2026-04-30 - **Description:** KubeVirt lets Kubernetes run virtual machines as first-class objects. Here is what the upstream project gives you and how Kubermatic Virtualization builds on top of it. - **Categories:** Products - **Tags:** KubeV, Kubernetes - **Authors:** Abubakar Siddiq Ango ## Kubernetes and the VM problem Cloud-native teams spent the last decade getting good at containers. Kubernetes became the default place to run containerized workloads, and almost every new service now ships as a container image. The catch is that most organizations still run a lot of virtual machines. Some of those VMs host applications that cannot be containerized without a rewrite. Others host databases, appliances, or operating-system-coupled workloads that are perfectly fine as VMs and would gain nothing from a container migration. For years, that split meant running two infrastructure stacks. A hypervisor platform such as VMware vSphere, OpenStack, or Proxmox for the VMs, and Kubernetes for the containers. Two control planes, two backup strategies, two skill sets, and two upgrade cycles. For teams running on their own bare-metal hardware, the split is even worse. They end up installing a hypervisor on bare metal, then creating VMs on the hypervisor, then running Kubernetes inside those VMs. That's a lot of layers to manage a container. ## What KubeVirt is [KubeVirt](https://kubevirt.io/) is a Kubernetes add-on that lets you run full virtual machines as native Kubernetes objects. A VM becomes a resource you can `kubectl apply`, watch, scale, label, and govern with the same tools you already use for Pods and Deployments. The project was started by Red Hat, with its [first tagged release v0.1.0 in December 2017](https://github.com/kubevirt/kubevirt/releases/tag/v0.1.0). It [joined the CNCF as a Sandbox project in September 2019](https://www.cncf.io/projects/kubevirt/) and was promoted to Incubating in April 2022. It is one of the most active projects in the CNCF landscape today. Under the hood, KubeVirt runs each VM inside a special Pod called the virt-launcher. The virt-launcher runs `qemu-kvm` and uses libvirt to manage the guest. Because the VM is wrapped in a Pod, it inherits almost everything Kubernetes gives Pods for free. It is scheduled by the Kubernetes scheduler, its lifecycle is reconciled by a controller, it has a Service and a label selector story, and NetworkPolicies that target its labels apply directly to the guest's traffic. KubeVirt's core resources are `VirtualMachine` (the long-lived, declarative VM), `VirtualMachineInstance` (the running instance, analogous to a Pod), and `VirtualMachineInstanceMigration` (a one-shot live migration request). The upstream [architecture guide](https://kubevirt.io/user-guide/architecture/) describes a `VirtualMachine` as behaving "similarly to a StatefulSet with `spec.replica` set to 1", which is the right mental model. ## Why Kubermatic built on KubeVirt At Kubermatic we have been working with KubeVirt for years. The first product of that work was a KubeVirt cloud provider inside Kubermatic Kubernetes Platform, shipped in KKP 2.22. That integration let operators provision user clusters on top of VMs that KKP created through KubeVirt on a shared infrastructure cluster. It proved the model. The more interesting question was what happens when you lean into KubeVirt all the way. Instead of using it as one cloud provider among many inside a Kubernetes management platform, what if the entire private cloud is built from Kubernetes primitives? That's what [Kubermatic Virtualization](https://www.kubermatic.com/products/kubermatic-virtualization/) is. It hit GA on November 27, 2025, after three years of engineering, and reached 1.1 in April 2026 with a self-service web UI, a declarative installer, and built-in authentication. The design goal was to remove the hypervisor middle layer from the bare-metal-to-container path. Install Kubernetes directly on bare metal, treat VMs as native Kubernetes objects, and run your tenant Kubernetes clusters inside those VMs, all from a single control plane. ## How Kubermatic Virtualization fits together Kubermatic Virtualization is not a single binary. It is a stack of well-known open-source components coordinated by a small set of Kubermatic-built controllers, a production-ready web UI, and a dedicated installer. The pieces that do the heavy lifting: - **[KubeOne](https://github.com/kubermatic/kubeone)** provisions and upgrades the bare-metal Kubernetes cluster that hosts everything else. This is the Infrastructure Cluster. - **Upstream KubeVirt** runs the VM workloads on that Infrastructure Cluster. - **[Kube-OVN](https://www.kube-ovn.io/)** provides the software-defined network. It is a [CNCF Sandbox project](https://www.cncf.io/projects/kube-ovn/) that brings OVN and OVS to Kubernetes, with VPCs, subnets, NAT gateways, Elastic IPs, and routing tables expressed as CRDs. - **KubeOne again** provisions tenant Kubernetes clusters inside the KubeVirt VMs when teams ask for them. - **Kubermatic's Virtualization control plane** wraps everything in a tenant/workspace model. The 1.1 release adds a production-ready web UI for end-to-end VM, networking, and storage management, and a `kubermatic-virtualization apply` installer that supports both an interactive wizard and declarative GitOps-style YAML, with self-healing on subsequent runs. The whole stack is also air-gap ready: every component ships as an OCI artifact, and the installer handles offline image mirroring out of the box. Everything below is standard Kubernetes, so if you already know how to operate a Kubernetes cluster, you already know most of how to operate this one. ## VirtualMachines and DataVolumes A `VirtualMachine` in KubeVirt is the declarative spec for a long-running VM. You set the desired CPU, memory, disks, network interfaces, and cloud-init data, and KubeVirt makes sure a matching `VirtualMachineInstance` exists. Disks are the interesting part. Instead of manually importing an image into your storage, you point at an image source and let the [Containerized Data Importer (CDI)](https://kubevirt.io/user-guide/storage/containerized_data_importer/) handle the download, format conversion, and PVC provisioning. CDI accepts HTTP/HTTPS URLs, container registries, upload via `virtctl`, existing PVC clones, `VolumeSnapshot` objects, and a few others. Here is a minimal `VirtualMachine` that boots an Ubuntu Jammy cloud image and installs nginx through cloud-init: ```yaml apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: ubuntu-web-server labels: app: web env: production spec: runStrategy: Always dataVolumeTemplates: - metadata: name: ubuntu-web-server-rootdisk spec: source: http: url: https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img storage: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi template: metadata: labels: app: web kubevirt.io/vm: ubuntu-web-server spec: domain: cpu: cores: 2 resources: requests: memory: 4Gi devices: disks: - name: rootdisk disk: bus: virtio bootOrder: 1 - name: cloudinitdisk disk: bus: virtio interfaces: - name: default masquerade: {} terminationGracePeriodSeconds: 180 networks: - name: default pod: {} volumes: - name: rootdisk dataVolume: name: ubuntu-web-server-rootdisk - name: cloudinitdisk cloudInitNoCloud: userData: | #cloud-config hostname: ubuntu-web-server ssh_authorized_keys: - ssh-rsa AAAA...your-public-key packages: - nginx - qemu-guest-agent runcmd: - systemctl enable --now nginx - systemctl enable --now qemu-guest-agent ``` The root disk is `ReadWriteOnce` because this VM is a single instance. If you want the VM to be live-migratable, you will need the root disk on a StorageClass that supports `ReadWriteMany`. More on that in the next section. ### Applying it and watching it come up Save the YAML above as `ubuntu-web-server.yaml`, substitute a real SSH public key under `ssh_authorized_keys`, and apply it into any namespace: ```bash kubectl create namespace kubevirt-demo kubectl -n kubevirt-demo apply -f ubuntu-web-server.yaml kubectl -n kubevirt-demo get vm,vmi,dv,pvc -w ``` The first time you run this, CDI pulls and converts the Ubuntu cloud image (~600 MB), so you will see the resources transition through a sequence of states: ```bash datavolume.cdi.kubevirt.io/ubuntu-web-server-rootdisk WaitForFirstConsumer N/A datavolume.cdi.kubevirt.io/ubuntu-web-server-rootdisk ImportInProgress 48.20% datavolume.cdi.kubevirt.io/ubuntu-web-server-rootdisk Succeeded 100.0% virtualmachineinstance.kubevirt.io/ubuntu-web-server Running 10.244.5.233 node-07 virtualmachine.kubevirt.io/ubuntu-web-server Running True ``` On a small lab cluster this typically completes in two to three minutes. The PVC is named `ubuntu-web-server-rootdisk` — taken literally from `dataVolumeTemplates[].metadata.name` with no VM-name prefix, which matters when you write RBAC or admission policies that match PVCs by pattern. Once the VMI is `Running`, `virtctl` gives you an SSH entry point without exposing a Service: ```bash virtctl -n kubevirt-demo ssh ubuntu@vm/ubuntu-web-server -i ~/.ssh/id_rsa ``` From inside the VM, nginx is serving and the qemu-guest-agent is reporting back to KubeVirt: ```bash $ systemctl is-active nginx qemu-guest-agent active active $ curl -sI http://127.0.0.1/ | head -2 HTTP/1.1 200 OK Server: nginx/1.18.0 (Ubuntu) ``` One cloud-init gotcha worth flagging: on Ubuntu cloud images, a group named `admin` already exists, so a `#cloud-config` that uses the top-level shortcut `user: admin` fails at `useradd` with "group admin exists" and then silently skips the `ssh_authorized_keys` step. Stick with the built-in `ubuntu` default user (as above), or declare a full `users:` list with `primary_group` and `groups` set explicitly. ## High availability, live migration, and maintenance Kubermatic Virtualization uses two different mechanisms for two different failure modes. **Unplanned node loss** is handled by reconciliation. If a bare-metal host dies, its `VirtualMachineInstance` becomes unavailable. The VM controller notices and creates a fresh `VirtualMachineInstance` on another suitable node, reattaching the existing PersistentVolumeClaims. The VM is restarted, not migrated, but recovery is automatic and uses only standard Kubernetes scheduling and storage primitives. This is infrastructure-level high availability without bolting on a separate clustering stack. **Planned maintenance** is handled by [live migration](https://kubevirt.io/user-guide/compute/live_migration/). KubeVirt supports three migration strategies: - **Pre-copy** is the default. Memory pages are copied to the target while the VM keeps running on the source, then execution switches over when state converges. Guests see no downtime. - **Post-copy** flips the model. The VM starts immediately on the target and pulls memory pages on demand. It's useful for memory-heavy workloads where pre-copy struggles to converge, but you opt in with `allowPostCopy: true`. - **Auto-converge** throttles the guest CPU to help pre-copy finish. Also opt-in, via `allowAutoConverge: true`. All migration traffic is TLS-encrypted by default. Live migration requires shared storage with `ReadWriteMany` access mode on the VM's PersistentVolumeClaims. When a bare-metal host is cordoned for maintenance, the Virtualization controllers evaluate each VM on that host. If the VM has compatible storage and a target node with enough capacity, live migration runs before the node is drained. If it can't, the system falls back to a safe restart on another node. Tenant Kubernetes clusters running inside those VMs stay available through the whole operation. ## Scale with VirtualMachinePools For workloads that need identical VMs in bulk, such as a fleet of web servers or build agents, KubeVirt offers [`VirtualMachinePool`](https://kubevirt.io/user-guide/user_workloads/pool/). It plays the same role for VMs that a Deployment plays for Pods: you declare a template and a replica count, and the pool keeps that many `VirtualMachine` objects running. Each VM gets its own PVC through the `DataVolumeTemplates` mechanism, with the pool's sequential suffix appended to the template name, so there is no shared-disk collision. ## Networking with Kube-OVN Kubermatic Virtualization uses Kube-OVN as its SDN. Kube-OVN integrates OVN (Open Virtual Network) and OVS (Open vSwitch) with Kubernetes, and it's a CNCF Sandbox project that matches the feature surface of commercial SDNs like NSX, entirely in open source. Tenancy at the network layer is expressed through Kube-OVN's `VPC` resource. Each tenant workspace can be assigned its own VPC with isolated subnets, routing tables, NAT gateways, and Elastic IPs, all declared as CRDs. Inside a VPC, VMs behave like any other workload. They can talk to each other, to Services, and to the outside world according to the routing you define. Because KubeVirt VMs run inside Pods, standard [Kubernetes NetworkPolicies](https://kubevirt.io/user-guide/network/networkpolicy/) apply to them directly. KubeVirt propagates the `VirtualMachineInstance`'s labels down to its virt-launcher Pod, and that label propagation is what makes a `podSelector`-based policy match a VM exactly the way it would match a Pod. Teams reuse the same policy tooling they already run for containers, and microsegmentation rules work uniformly across VMs and Pods. For workloads that need low-latency networking, the platform supports **SR-IOV** for direct hardware access. ## RBAC and multi-tenancy Because VMs are native Kubernetes objects, KubeVirt gets Kubernetes RBAC for free. Upstream ships three default ClusterRoles, documented in the [authorization guide](https://kubevirt.io/user-guide/cluster_admin/authorization/): - `kubevirt.io:view` grants read-only access to VM resources. - `kubevirt.io:edit` allows creating, modifying, and accessing VMs, including console and VNC. - `kubevirt.io:admin` adds runtime configuration control. These are bound at the namespace level via `RoleBinding` for tenant-scoped access, or cluster-wide via `ClusterRoleBinding` for operators. Custom roles let you narrow permissions further, for example allowing a user to create VMs but not attach GPUs or trigger live migration. Above the RBAC layer, Kubermatic Virtualization 1.1 ships built-in authentication with three modes: No Auth, Basic Auth, and OIDC/SSO, with an optional in-cluster Dex deployment for enterprise-grade login without an external identity provider. Once a user is authenticated, the same Kubernetes RBAC binds them to whatever scope the operator has defined. The platform also installs a default set of Kyverno policies that enforce common VM security best practices, so tenants inherit a baseline policy posture without operator intervention. Combined with Kube-OVN's VPC-level isolation and standard Kubernetes `ResourceQuota`, this gives each tenant a namespace with its own network boundary, identity layer, RBAC policies, baseline security policies, and resource limits, all enforced through primitives your operators already understand. ## GPU support Kubermatic Virtualization exposes GPUs to VMs through two mechanisms, both declared under `spec.domain.devices.gpus` on the VM spec and documented in the [host-devices guide](https://kubevirt.io/user-guide/compute/host-devices/). **PCI passthrough** dedicates a whole physical GPU to one VM using the VFIO framework. The host releases the GPU from its native driver, binds it to vfio-pci, and passes it into the guest. Performance is near-native. This requires IOMMU support (Intel VT-d or AMD-Vi) enabled in firmware, and is the right choice for workloads that want a full GPU, such as ML training or scientific simulation. **Mediated devices (vGPU)** split a physical GPU across multiple VMs using the Linux `mdev` framework. The cluster admin declares the allowed mediated-device types in the KubeVirt CR, the vendor driver on the host creates the mdev instances, and VMs request them like any other device. NVIDIA vGPU requires NVIDIA's driver on the host, and other vendors have equivalent driver requirements. This is the right choice for inference, remote desktops, and visualization, where full-GPU dedication is wasteful. In both cases, GPU-bearing nodes are labeled, and the Kubernetes scheduler places VMs that request GPUs on nodes that can satisfy the request. ## One platform, one control plane With Kubermatic Virtualization the boundary between container management and VM management stops being a meaningful line in your architecture. You run both on the same Kubernetes, govern both with the same APIs, and observe both through the same pipeline. Tenant Kubernetes clusters come up inside VMs that your operators never had to provision manually. Day-two operations, from live migration to backups to RBAC, all live in one control plane. For what's new in the latest release, see [Meet Kubermatic Virtualization 1.1](/blog/meet-kubermatic-virtualization-1-1-web-ui-gitops-installer-and-advanced-networking/). If you want to see it in action, [book a demo](https://www.kubermatic.com/demo/) or [browse the documentation](https://docs.kubermatic.com/kubermatic-virtualization/latest/). --- ## Kubernetes v1.36 "Haru" Arrives After the Frost - **URL:** https://www.kubermatic.com/blog/kubernetes-v1-36-haru-arrives-after-the-frost/ - **Date:** 2026-04-30 - **Description:** Kubernetes v1.36 "Haru" ships 70 enhancements, including workload-aware scheduling, fine-grained kubelet authorization, and Pod-level hardware health. Here's what platform teams should act on this quarter. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Abubakar Siddiq Ango Kubernetes v1.36, codenamed **Haru**, ships with 70 enhancements: 18 Stable, 25 Beta, 25 Alpha. The logo reimagines Hokusai's *Fine Wind, Clear Morning*. The release lands three changes platform teams should care about: workload-aware scheduling, fine-grained kubelet API authorization, and Pod-level hardware health reporting. Each has been building for releases. ## Workload-aware scheduling In v1.35, native gang scheduling ([KEP-4671](https://github.com/kubernetes/enhancements/issues/4671)) acknowledged what ML training and HPC orchestration share: they don't fit the one-pod-at-a-time scheduling model Kubernetes was born with. v1.36 goes further. **Workload Aware Scheduling** enters alpha, with a decoupled PodGroup API ([KEP-5832](https://github.com/kubernetes/enhancements/issues/5832)) and native Job controller integration. Related pods become a single logical entity: the group is evaluated for atomicity rather than each pod winning or losing placement on its own. The direction matters more than the specific API shape, which will still evolve. Kubernetes is retrofitting HPC semantics into a scheduler designed for stateless web services. Over the next two or three releases, expect scheduler primitives that handle training groups, inference fleets, and multi-node jobs as first-class citizens. Where workloads span cluster boundaries — the default in any multi-tenant or multi-region operator — workload-aware scheduling is more valuable paired with a control plane that can place the whole workload, not just its pods. This is what [kcp](https://kcp.io/) has been modelling at the control-plane layer, and why Kubermatic has bet on it. If you're building for AI or HPC-adjacent workloads, evaluate your scheduling stack this cycle. ## Fine-grained kubelet authorization **Fine-grained kubelet API Authorization** ([KEP-2862](https://github.com/kubernetes/enhancements/issues/2862)) graduates to GA. The `nodes/proxy` permission, the catch-all that monitoring and diagnostic tools have historically used to talk to the kubelet API, can now be split into per-endpoint authorization. Prometheus gets only the endpoints it scrapes; log collectors get only the endpoints they consume. The capability has been beta and default-on since v1.33, so most clusters can already enable it; v1.36 adds the stability commitment. Pair this with v1.35's Pod certificates for workload identity ([KEP-4317](https://github.com/kubernetes/enhancements/issues/4317)) and the pattern is clear: the authorization surface is being broken into smaller, auditable grants, with state and rotation logic moved closer to the components that need them. The timing matters. DORA's March 2026 reporting deadline already shifted how European financial institutions think about third-party authorization. NIS2 transposition is uneven but accelerating, and the EU AI Act's high-risk requirements activate in August. An auditor who sees every monitoring component holding broad `nodes/proxy` will ask why least privilege was optional. In managed environments like Kubermatic Kubernetes Platform, fine-grained kubelet authz can be a platform default rather than a per-tenant audit exercise. ## Resource health status for Pods **Resource Health Status for Pods** ([KEP-4680](https://github.com/kubernetes/enhancements/issues/4680)) enters beta. A new `allocatedResourcesStatus` field on Pod `.status` reports the health of allocated devices, surfaced through `kubectl describe pod`, and works across both the older Device Plugins framework and the newer Dynamic Resource Allocation (DRA) pipeline. For most of Kubernetes' history, a Pod was considered ready by its process alone. The hardware behind it — the GPU under the CUDA library, the SmartNIC behind the VF, the FPGA — was invisible to the scheduler and to the Pod's own status. If a device degraded, the Pod kept reporting Ready while its workload failed. 1.36 recognises that where heterogeneous compute is the default, Pod readiness is incomplete unless the devices a Pod depends on are healthy. Expect this field to become the foundation for automated remediation: evicting pods whose GPUs have entered a degraded state, rescheduling to a node whose accelerators are alive, or surfacing the real failure mode in `kubectl describe` rather than in vendor driver logs. ## Deprecations and removals The biggest items for platform teams: - **Service [`.spec.externalIPs`](https://kubernetes.io/docs/concepts/services-networking/service/#external-ips) is deprecated.** A long-standing security weak point ([CVE-2020-8554](https://www.cve.org/CVERecord?id=CVE-2020-8554)). Removal scheduled for v1.43; migrate to LoadBalancer, NodePort, or Gateway API. ([KEP-5707](https://github.com/kubernetes/enhancements/issues/5707).) - **`gitRepo` volume driver is permanently disabled.** Deprecated since v1.11; a security issue allowed code execution as root on the node. Replace with init containers or a git-sync sidecar. ([KEP-5040](https://github.com/kubernetes/enhancements/issues/5040).) - **Portworx in-tree volume plugin migration to CSI graduates to GA.** [CSI migration](https://kubernetes.io/blog/2022/09/26/storage-in-tree-to-csi-migration-status-update-1.25/) is mandatory. - **Ingress NGINX is [retired](https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/).** As of March 24, 2026, SIG Network ended releases, bugfixes, and security updates. Existing deployments continue but are unmaintained. Our [KubeLB-based migration walkthrough](/blog/ingress-nginx-retiring-transition-to-gatewayapi-with-kubelb-cli/) is the operational playbook. Review the [v1.36 changelog](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.36.md) before upgrading, and pay attention to anything beta or deprecated for more than two releases. ## What this means for Kubermatic users **Ingress NGINX → Gateway API, made operational.** If you're running Ingress NGINX on KKP or anywhere else, the retirement is now in effect. KubeLB v1.3 ships an [automated Ingress-to-Gateway-API converter](https://docs.kubermatic.com/kubelb/v1.3/ingress-to-gateway-api/) that audits your cluster, previews the Gateway + HTTPRoute resources it will generate, handles TLS secret movement, and tracks conversion status per resource. Our earlier writeup [*Ingress NGINX is Retiring: Use KubeLB to Transition to Gateway API*](/blog/ingress-nginx-retiring-transition-to-gatewayapi-with-kubelb-cli/) walks the migration end to end. **Fine-grained kubelet authz, now stable.** The feature has been beta and default-on since Kubernetes v1.33, so KKP customers running supported Kubernetes versions (1.33+) can adopt it today. v1.36 promotes it to GA — turning the beta promise into a stability commitment. For operators running regulated workloads under DORA, NIS2, or the EU AI Act, that shortens the path to a defensible authorization posture. ## Community The v1.36 cycle ran 15 weeks, January 12 to April 22, 2026, under release lead Ryota Sawada. Contributions to Kubernetes core came from **491 individuals across 106 companies**; in the wider cloud-native ecosystem, **2,235 contributors from 370 companies** took part. To everyone who landed a line of code, reviewed a PR, fixed a doc, drafted a KEP, or shadowed a release-team role: thank you. The full release team roster is in the [release-1.36 repository](https://github.com/kubernetes/sig-release/tree/master/releases/release-1.36). ## Looking forward Three things from 1.36 belong on this quarter's review agenda. Audit your RBAC for components ever granted `nodes/proxy`. Most don't need it. Fine-grained kubelet authz being GA means closing the gap between how your observability stack works today and how an auditor will expect it to work is a small config change. Take stock of your scheduling posture. If your platform will run AI, ML, or HPC-adjacent workloads in the next 12 months, the scheduler evolution that started in 1.35 and accelerated in 1.36 isn't going to stop. Gang scheduling, workload-aware scheduling, and the settling of the PodGroup API will reshape capacity planning and multi-cluster placement. Extend your observability stack to include device health. `allocatedResourcesStatus` makes the hardware layer visible alongside Pod status. Adopt it before you need it. ## Learn more - [Official Kubernetes v1.36 release announcement](https://kubernetes.io/blog/2026/04/22/kubernetes-v1-36-release/) - [Kubernetes v1.36 CHANGELOG](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.36.md) - [Release-1.36 tracking README](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.36/README.md) --- ## Creating Your First Virtual Machine with KubeVirt - **URL:** https://www.kubermatic.com/learn/kubevirt/creating-your-first-vm-with-kubevirt/ - **Date:** 2026-04-30 [Learn](/learn/) / [Kubevirt](/learn/kubevirt/) / Creating Your First Virtual Machine with KubeVirt kubevirt # Creating Your First Virtual Machine with KubeVirt ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Apr 27, 2026 3 min read Beginner [getting-started](/learn/?tag=getting-started) [virtualization](/learn/?tag=virtualization) [virtctl](/learn/?tag=virtctl) #### Prerequisites - [Installed KubeVirt](/learn/kubevirt/installing-kubevirt/) on your cluster - kubectl and virtctl on your workstation - Basic familiarity with applying Kubernetes manifests A `VirtualMachine` is a Kubernetes object. You write it as YAML, apply it with `kubectl apply -f`, and it shows up under `kubectl get vm` like any other resource — namespaced, RBAC-able, watchable, governed by labels. This tutorial turns that idea into a running Linux VM in about fifteen minutes. ## Why a containerDisk The fastest way to a working VM is to skip image-import altogether. The kubevirt/containerdisks project publishes Ubuntu, Fedora, Debian, openSUSE, and CentOS Stream cloud images packaged inside container images at `quay.io/containerdisks/*`. Your cluster pulls one the same way it pulls any other container — no CDI, no PVC, no waiting for a 600 MB qcow2 to download. Container disks are read-only and ephemeral, which is fine for learning the shape of the API. Persistent storage comes in a later tutorial. ## The manifest Save this as `vm.yaml`: ```yaml apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: testvm spec: runStrategy: Halted template: metadata: labels: kubevirt.io/size: small kubevirt.io/domain: testvm spec: domain: devices: disks: - name: containerdisk disk: bus: virtio - name: cloudinitdisk disk: bus: virtio interfaces: - name: default masquerade: {} resources: requests: memory: 1Gi cpu: "1" networks: - name: default pod: {} volumes: - name: containerdisk containerDisk: image: quay.io/containerdisks/ubuntu:22.04 - name: cloudinitdisk cloudInitNoCloud: userData: | #cloud-config password: ubuntu chpasswd: { expire: False } ssh_pwauth: True ``` `runStrategy: Halted` is the safe default. It tells KubeVirt: *create the VM object, don’t boot it.* You apply the manifest, inspect what you got, then start the VM explicitly. That separation is useful — it stops you from accidentally launching workloads while you debug a YAML error. The `cloudInitNoCloud` block ships first-boot configuration to the guest. Here it sets the `ubuntu` user’s password to `ubuntu` and allows password-based serial console login. The next tutorial swaps that for SSH-key auth. ## Apply, start, attach Create a namespace for the work and apply the manifest: ```bash export NS=kubev-lab-$(whoami) kubectl create namespace $NS kubectl config set-context --current --namespace=$NS kubectl apply -f vm.yaml kubectl get vm testvm ``` You should see the VM as `Stopped`, `Ready: False`. The object exists, no VMI yet — exactly what `runStrategy: Halted` promises. Start it: ```bash virtctl start testvm kubectl get vmi testvm --watch ``` Watch the `VirtualMachineInstance` walk through `Scheduling` → `Scheduled` → `Running`. Press Ctrl+C once it’s running. Behind the scenes, KubeVirt has created a `virt-launcher` pod on a worker node — the QEMU/KVM process that *is* your VM: ```bash kubectl get pods -l kubevirt.io/domain=testvm ``` Now open the serial console: ```bash virtctl console testvm ``` Wait 30–60 seconds for cloud-init to finish on first boot. You’ll land on an Ubuntu login prompt. Sign in as `ubuntu` / `ubuntu` and poke around: ```bash uname -a cat /etc/os-release ip addr ``` Detach with `Ctrl+]` (Control plus close-square-bracket). **Don’t type `exit`** — that logs you out of the guest but leaves virtctl attached, which surprises whoever connects next. ## Three layers, one VM The mental model that makes everything else click: a running KubeVirt VM is three Kubernetes objects stacked on top of each other. ```bash kubectl get vm,vmi,pods -l kubevirt.io/domain=testvm ``` You’ll see one `VirtualMachine` (the long-lived spec), one `VirtualMachineInstance` (the running instance, deleted on stop), and one `virt-launcher-*` pod (the actual hypervisor process). When you stop the VM with `virtctl stop`, the VMI and pod disappear; the VM object stays. Start it again and a fresh VMI and pod come back. That’s the same reconciliation pattern Kubernetes uses for Deployments and Pods — it just operates on a hypervisor. ## What’s next Leave `testvm` running. The next tutorial picks up here, walks through the four lifecycle operations (`start`, `stop`, `pause`, `unpause`), and replaces the password with an SSH key so you can connect with `virtctl ssh` instead of the serial console. #### Resources - [KubeVirt — creating VMs](https://kubevirt.io/user-guide/user_workloads/creating_vms/) - [KubeVirt — accessing VMs](https://kubevirt.io/user-guide/user_workloads/accessing_virtual_machines/) - [kubevirt/containerdisks (Ubuntu/Fedora/Debian images)](https://github.com/kubevirt/containerdisks) #### On This Page - [Why a containerDisk](#why-a-containerdisk) - [The manifest](#the-manifest) - [Apply, start, attach](#apply-start-attach) - [Three layers, one VM](#three-layers-one-vm) - [What’s next](#whats-next) --- ## Enabling the Kubermatic Virtualization Dashboard - **URL:** https://www.kubermatic.com/learn/kubermatic-virtualization/kubermatic-virtualization-dashboard/ - **Date:** 2026-04-30 [Learn](/learn/) / [Kubermatic-Virtualization](/learn/kubermatic-virtualization/) / Enabling the Kubermatic Virtualization Dashboard kubermatic-virtualization # Enabling the Kubermatic Virtualization Dashboard ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Apr 27, 2026 4 min read Beginner [dashboard](/learn/?tag=dashboard) [virtualization](/learn/?tag=virtualization) [operator-ui](/learn/?tag=operator-ui) #### Prerequisites - A running Kubermatic Virtualization cluster — `kubev apply` succeeded against your `cluster.yaml` - kubectl with `$KUBECONFIG` pointing at the KubeV cluster - quay.io credentials in `KUBEV_USERNAME` / `KUBEV_PASSWORD` (or an inline `imagePullSecret:` in `cluster.yaml`) The Kubermatic Virtualization Dashboard is the per-cluster operator UI introduced in v1.1.0. It gives you a VM-aware browser — start/stop/console controls, Nodes view, Data Volumes, Firewalls, Load Balancers — for the cluster it lives in. It is shipped and reconciled by the `kubev` installer itself, not as a separate Helm chart or add-on. Enabling it is one config block and a re-apply. This tutorial covers turning it on, the three authentication modes, and the access pattern for both lab and production. ## Per-cluster, not multi-cluster The dashboard scope matters: it shows the cluster it’s installed in, not a fleet. If you operate many clusters and want a single cross-cluster inventory, **KKP** stays the right tool — and the two complement each other rather than overlap. KKP answers *“which cluster?”*; the Kubermatic Virtualization Dashboard answers *“what’s happening inside that cluster?”* If you only run one cluster, you might never need KKP. The dashboard plus `kubectl` is enough. ## What gets installed Enabling the dashboard creates: - A new namespace, `kubermatic-virtualization` - Two Deployments: `kubev-api-server` (talks to the Kubernetes API on the user’s behalf) and `kubev-dashboard` (a React SPA served by nginx) - A Service named `kubev-dashboard` on port 8080 - The image-pull secret needed to pull the dashboard images from quay.io Both pods are small. There’s no separate database — the dashboard reads and writes through the same Kubernetes API your `kubectl` already uses, which means YAML stays the source of truth. The UI is a convenience layer; if anything looks off in it, `kubectl get` and `kubectl describe` remain the fall-back. ## Pull-secret pre-flight The dashboard images live on quay.io and are gated. The installer pre-flights for either of: - `KUBEV_USERNAME` and `KUBEV_PASSWORD` env vars (the same quay.io credentials used elsewhere in the install) - An inline `imagePullSecret:` block in `cluster.yaml` containing a docker-config JSON Apply is rejected if neither is present. This is a known stumbling block — debugging “why aren’t my pods pulling?” after `apply` succeeds is more painful than failing fast on missing credentials, which is why the installer does the latter. Confirm before you start: ```bash echo "${KUBEV_USERNAME:-MISSING}" test -n "$KUBEV_PASSWORD" && echo "set" || echo "MISSING" ``` ## Add the `dashboard:` block Open your existing `cluster.yaml` and add a `dashboard:` block. The minimal lab version (no auth, port-forward access): ```yaml dashboard: enabled: true auth: none: {} ``` The minimal basic-auth version: ```yaml dashboard: enabled: true auth: basic: {} # uses KUBEV_USERNAME / KUBEV_PASSWORD ``` The OIDC version (production standard — works with Keycloak, Dex, Okta, Azure AD, Google, anything that speaks OIDC): ```yaml dashboard: enabled: true dashboardURL: https://kubev.example.com auth: oidc: issuerURL: https://keycloak.example.com/realms/kubev clientID: kubev-dashboard clientSecret: <generated> redirectURL: https://kubev.example.com/oauth/callback ``` Note `dashboardURL` — for OIDC the issuer needs a stable redirect target, so this isn’t optional in production. ## Apply Re-run the installer: ```bash kubermatic-virtualization apply -f cluster.yaml ``` The installer is declarative and self-healing — re-running it picks up the new `dashboard:` block, creates the namespace and Deployments, and reconciles them on every subsequent apply. There’s no separate `dashboard install` step. Watch the rollout: ```bash kubectl -n kubermatic-virtualization rollout status deploy/kubev-api-server kubectl -n kubermatic-virtualization rollout status deploy/kubev-dashboard ``` ## Lab access via port-forward For an isolated lab cluster, port-forward straight to the Service: ```bash kubectl port-forward svc/kubev-dashboard -n kubermatic-virtualization 8080:8080 ``` Open `http://localhost:8080`. With `auth.none` you’ll land directly on the Dashboard view. With `auth.basic` you’ll be challenged for the same `KUBEV_USERNAME` / `KUBEV_PASSWORD` you set on the install. The left sidebar groups the operational surface: - **Dashboard** — resource overview tiles - **Compute** — Virtual Machines, VM Pools, Auto Scaling - **Infrastructure** — Nodes, Instance Types - **Storage** — Data Volumes, Images - **Network** — VPCs, Subnets, Load Balancers - **Security** — Firewalls, SSH Keys VM detail view has four tabs: **Networking**, **Disks**, **Monitoring**, **Console**. The Console tab is the same serial console you’ve been reaching with `virtctl console`, embedded in the browser. ## Production access `kubectl port-forward` is fine for a lab. For production, front the `kubev-dashboard` Service with an Ingress (TLS-terminated) or a LoadBalancer Service, point `dashboardURL:` at the externally-reachable URL, and use `auth.oidc` against your existing identity provider. Production exposure is out of scope here, but the Kubermatic Virtualization operator handbook walks through the full pattern. ## What’s next The dashboard is the entry point most operators end up using day-to-day. Underneath it, every screen is a read/write against the same Kubernetes API — so `kubectl` stays as the diagnostic layer when something doesn’t look right in the UI. The next tutorial in this series covers GitOps installs, where `kubev apply` runs from a CI pipeline and the dashboard becomes a read-mostly window into a cluster that’s reconciled from version control. #### Resources - [Kubermatic Virtualization v1.1 — Dashboard installation](https://docs.kubermatic.com/kubermatic-virtualization/v1.1.0/installation/dashboard/) - [Kubermatic Virtualization v1.1 — cluster.yaml reference](https://docs.kubermatic.com/kubermatic-virtualization/v1.1.0/references/cluster-configuration/) - [Kubermatic Virtualization v1.1 — release notes](https://docs.kubermatic.com/kubermatic-virtualization/v1.1.0/release-notes/) #### On This Page - [Per-cluster, not multi-cluster](#per-cluster-not-multi-cluster) - [What gets installed](#what-gets-installed) - [Pull-secret pre-flight](#pull-secret-pre-flight) - [Add the `dashboard:` block](#add-the-dashboard-block) - [Apply](#apply) - [Lab access via port-forward](#lab-access-via-port-forward) - [Production access](#production-access) - [What’s next](#whats-next) --- ## Installing Kubermatic Virtualization with the Declarative Installer - **URL:** https://www.kubermatic.com/learn/kubermatic-virtualization/installing-kubermatic-virtualization/ - **Date:** 2026-04-30 [Learn](/learn/) / [Kubermatic-Virtualization](/learn/kubermatic-virtualization/) / Installing Kubermatic Virtualization with the Declarative Installer kubermatic-virtualization # Installing Kubermatic Virtualization with the Declarative Installer ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Apr 27, 2026 4 min read Beginner [getting-started](/learn/?tag=getting-started) [installation](/learn/?tag=installation) [gitops](/learn/?tag=gitops) #### Prerequisites - A bare-metal Kubernetes cluster, or hosts that the installer can provision into one - kubectl with cluster-admin access on the target cluster - quay.io credentials in `KUBEV_USERNAME` / `KUBEV_PASSWORD` (provided to your account) - The `kubermatic-virtualization` CLI on your workstation Kubermatic Virtualization 1.1 introduced a declarative installer: a single `kubermatic-virtualization apply -f cluster.yaml` command that handles install, upgrade, and self-heal. You can drive it interactively with a wizard the first time, then check the resulting `cluster.yaml` into version control and reconcile from CI on every subsequent change. This tutorial walks both paths. ## What gets installed Kubermatic Virtualization is a stack of well-known open-source components plus Kubermatic’s own controllers and UI. The installer reconciles all of it from a single config file: - **KubeOne** provisions and upgrades the bare-metal Kubernetes cluster (the “Infrastructure Cluster”) - **Upstream KubeVirt** runs the VM workloads on that cluster - **Kube-OVN** provides the SDN — VPCs, subnets, NAT gateways, Elastic IPs as CRDs - **Containerized Data Importer (CDI)** handles cloud-image imports into PVCs - **Longhorn** ships as the default storage class; **MetalLB** as the default load balancer - **Kyverno** enforces a baseline set of VM security policies - **The Kubermatic Virtualization control plane** (API server, controllers, [web UI](/learn/kubermatic-virtualization/kubermatic-virtualization-dashboard/)) You don’t have to install any of those individually. The installer reconciles the whole stack from your `cluster.yaml`. ## Generate a starter cluster.yaml The installer ships a `config print` subcommand that emits a template you can edit: ```bash kubermatic-virtualization config print \ --enable-metallb \ --enable-longhorn \ --control-plane-hosts 3 \ --worker-hosts 3 \ > cluster.yaml ``` Open `cluster.yaml` and fill in: - **`infrastructure.controlPlaneHosts:`** — IPs and SSH details for the three control-plane nodes - **`infrastructure.workerHosts:`** — IPs and SSH details for worker nodes - **`networking.cni.kubeOVN:`** — VPC subnet ranges (the defaults are usually fine for a lab) - **`auth:`** — leave as-is for now; you’ll come back to it for OIDC - **`dashboard:`** — see the [dashboard tutorial](/learn/kubermatic-virtualization/kubermatic-virtualization-dashboard/) for the block The CLI accepts SSH key files or agent-forwarded sessions for the host steps. Once the file is filled in, you have a single artifact that describes your entire cluster. ## Pre-flight The installer pre-flights several things and refuses to apply if any are missing: - `KUBEV_USERNAME` and `KUBEV_PASSWORD` set (or an inline `imagePullSecret:` in `cluster.yaml`) — used to pull the gated images from quay.io - All listed hosts reachable over SSH from the workstation running the installer - Hosts meet the minimum hardware floor (CPU / RAM / disk) and have hardware virtualization enabled in firmware - The Kubernetes version requested is supported by KubeOne for the providers you’ve declared ```bash echo "${KUBEV_USERNAME:-MISSING}" test -n "$KUBEV_PASSWORD" && echo "set" || echo "MISSING" kubermatic-virtualization apply -f cluster.yaml --dry-run ``` `--dry-run` walks the pre-flight without making changes. Fix anything that fails before you proceed. ## Apply ```bash kubermatic-virtualization apply -f cluster.yaml ``` The first apply on a fresh cluster takes 20–40 minutes. The installer: 1. Provisions the bare-metal Kubernetes cluster via KubeOne 2. Installs Kube-OVN as the CNI 3. Installs Longhorn and MetalLB 4. Installs KubeVirt + CDI 5. Installs the Kubermatic Virtualization control plane (and the dashboard if you enabled it) 6. Applies the default Kyverno policies You can watch progress in the installer output and in `kubectl` once the API is reachable: ```bash export KUBECONFIG=$(pwd)/kubeconfig # the installer drops this in the working dir kubectl get nodes kubectl get pods -A | grep -E "kubevirt|kube-ovn|longhorn|kubermatic-virtualization" ``` ## GitOps from here Once the cluster is up and `cluster.yaml` reflects its full configuration, the file is the single source of truth. Subsequent changes — upgrading Kubernetes, swapping the CNI’s IP ranges, enabling the dashboard, adding worker nodes — all happen by editing `cluster.yaml` and re-running `apply`: ```bash kubermatic-virtualization apply -f cluster.yaml ``` The installer is declarative and self-healing. Re-applying picks up only what’s changed and reconciles. That’s the pattern that makes the installer CI-friendly: check `cluster.yaml` into a repo, run `apply` on every merged PR, let the installer drive the cluster toward the declared state. A pragmatic split: the wizard for the first install on a fresh cluster, then GitOps from there. The wizard is for figuring out the right shape of `cluster.yaml`. Once you have it, you don’t need the wizard again. ## What’s next A live cluster is the floor. The next tutorial in the series covers [enabling the Kubermatic Virtualization Dashboard](/learn/kubermatic-virtualization/kubermatic-virtualization-dashboard/) — the per-cluster web UI introduced in 1.1 — including the three authentication modes (None / Basic / OIDC). After that, the [KubeVirt Getting Started series](/learn/kubevirt/) takes over for the VM workload patterns: creating VMs, lifecycle, networking, and persistent storage. #### Resources - [Kubermatic Virtualization v1.1 — installation](https://docs.kubermatic.com/kubermatic-virtualization/v1.1.0/installation/) - [Kubermatic Virtualization v1.1 — cluster.yaml reference](https://docs.kubermatic.com/kubermatic-virtualization/v1.1.0/references/cluster-configuration/) - [Kubermatic Virtualization v1.1 — release notes](https://docs.kubermatic.com/kubermatic-virtualization/v1.1.0/release-notes/) - [Meet Kubermatic Virtualization 1.1](/blog/meet-kubermatic-virtualization-1-1-web-ui-gitops-installer-and-advanced-networking/) #### On This Page - [What gets installed](#what-gets-installed) - [Generate a starter cluster.yaml](#generate-a-starter-clusteryaml) - [Pre-flight](#pre-flight) - [Apply](#apply) - [GitOps from here](#gitops-from-here) - [What’s next](#whats-next) --- ## VM Lifecycle and SSH Access in KubeVirt - **URL:** https://www.kubermatic.com/learn/kubevirt/vm-lifecycle-and-ssh-access/ - **Date:** 2026-04-30 [Learn](/learn/) / [Kubevirt](/learn/kubevirt/) / VM Lifecycle and SSH Access in KubeVirt kubevirt # VM Lifecycle and SSH Access in KubeVirt ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Apr 27, 2026 3 min read Beginner [virtualization](/learn/?tag=virtualization) [cloud-init](/learn/?tag=cloud-init) [virtctl](/learn/?tag=virtctl) #### Prerequisites - [Created your first VM](/learn/kubevirt/creating-your-first-vm-with-kubevirt/) — `testvm` running in your namespace - An SSH key pair on your workstation (`ssh-keygen -t ed25519` if you don’t have one) A KubeVirt VM has four lifecycle verbs: `start`, `stop`, `pause`, and `unpause`. **Stop** deletes the `VirtualMachineInstance` and its `virt-launcher` pod — memory and CPU are released. **Pause** freezes the guest at the hypervisor level but keeps the pod and memory in place. Stop is cheap; pause is instant. You drive the lifecycle two ways: `virtctl` for ergonomics, or `kubectl patch` against the VM’s `runStrategy` field for GitOps. Both end at the same controller reconciliation. Use `virtctl` interactively. Use `kubectl patch` (or, ideally, a checked-in YAML) when you want every state transition recorded in version control. ## The four operations Stop the VM and wait for the VMI to disappear: ```bash virtctl stop testvm kubectl wait --for=delete vmi/testvm --timeout=120s ``` Then start it again: ```bash virtctl start testvm kubectl wait --for=jsonpath='{.status.phase}'=Running vmi/testvm --timeout=180s ``` Pause: ```bash virtctl pause vm testvm kubectl get vmi testvm -o jsonpath='{.status.conditions[?(@.type=="Paused")].status}' ``` The `Paused` condition flips to `True`. Unpause: ```bash virtctl unpause vm testvm ``` ## The same flow via `kubectl patch` `virtctl start` is a wrapper. The same lifecycle change happens when you flip `spec.runStrategy` from `Always` to `Halted` or back: ```bash printf "spec:\n runStrategy: Halted\n" > /tmp/halted.yaml kubectl patch vm testvm --type merge --patch-file /tmp/halted.yaml ``` ```bash printf "spec:\n runStrategy: Always\n" > /tmp/running.yaml kubectl patch vm testvm --type merge --patch-file /tmp/running.yaml ``` Both reach the same controller and reconcile the VMI accordingly. For CI/CD pipelines, the `kubectl patch` form removes the virtctl dependency and slots into any tooling that already speaks Kubernetes. ## SSH instead of the serial console The first tutorial used `virtctl console` and a guest password, which is fine for poking around but not how anyone actually wants to connect. KubeVirt’s answer is `cloudInitNoCloud` — a tiny virtual disk delivered to the guest at first boot that the cloud-init package inside Ubuntu reads as a NoCloud datasource. Anything cloud-init understands works: users, packages, files, runcmd, and the one we want here, `ssh_authorized_keys`. Cloud-init only runs on first boot, so to switch from a password to an SSH key you have to delete and re-apply the VM. Confirm your public key is exported: ```bash export SSH_PUBKEY="$(cat ~/.ssh/id_ed25519.pub)" echo "$SSH_PUBKEY" ``` Then update `vm.yaml` — replace the cloudInitNoCloud `userData` block from the previous tutorial with: ```yaml volumes: - name: containerdisk containerDisk: image: quay.io/containerdisks/ubuntu:22.04 - name: cloudinitdisk cloudInitNoCloud: userData: | #cloud-config ssh_authorized_keys: - PASTE_YOUR_PUBLIC_KEY_HERE ``` Or render it from a template that picks up `$SSH_PUBKEY`: ```bash envsubst < vm.yaml.template > vm.yaml grep -A2 ssh_authorized_keys vm.yaml ``` Delete the old VM and re-apply: ```bash kubectl delete vm testvm kubectl apply -f vm.yaml virtctl start testvm kubectl wait --for=jsonpath='{.status.phase}'=Running vmi/testvm --timeout=180s ``` Give cloud-init a minute after the VMI hits Running to finish provisioning the key into `/home/ubuntu/.ssh/authorized_keys`, then connect: ```bash virtctl ssh -i ~/.ssh/id_ed25519 ubuntu@vmi/testvm ``` You’ll land in a shell — `ubuntu@testvm:~$` — without a password prompt. `virtctl ssh` is virtctl proxying a local SSH process through the Kubernetes API to the VM; you don’t need port-forward setup or an externally-routable VM IP. The `vmi/` prefix is required on KubeVirt v1.5.x and newer; the old bare `<user>@<vm>` form is deprecated. Confirm the key landed where you expect: ```bash whoami cat ~/.ssh/authorized_keys exit ``` ## What’s next `testvm` is now key-authenticated and reachable through `virtctl ssh`. The next tutorials cover [VM networking](/learn/kubevirt/vm-networking-with-kubevirt/) (how the guest IP relates to the pod IP, how to expose a service running inside the VM) and [persistent storage](/learn/kubevirt/vm-storage-with-datavolumes/) (so your data survives when the VM stops). #### Resources - [KubeVirt — VM lifecycle](https://kubevirt.io/user-guide/user_workloads/lifecycle/) - [KubeVirt — startup scripts and cloud-init](https://kubevirt.io/user-guide/user_workloads/startup_scripts/) - [cloud-init NoCloud datasource](https://cloudinit.readthedocs.io/en/latest/reference/datasources/nocloud.html) #### On This Page - [The four operations](#the-four-operations) - [The same flow via `kubectl patch`](#the-same-flow-via-kubectl-patch) - [SSH instead of the serial console](#ssh-instead-of-the-serial-console) - [What’s next](#whats-next) --- ## VM Networking with KubeVirt: Masquerade, DNS, and Services - **URL:** https://www.kubermatic.com/learn/kubevirt/vm-networking-with-kubevirt/ - **Date:** 2026-04-30 [Learn](/learn/) / [Kubevirt](/learn/kubevirt/) / VM Networking with KubeVirt: Masquerade, DNS, and Services kubevirt # VM Networking with KubeVirt: Masquerade, DNS, and Services ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Apr 27, 2026 4 min read Beginner [virtualization](/learn/?tag=virtualization) [networking](/learn/?tag=networking) [services](/learn/?tag=services) #### Prerequisites - [VM lifecycle and SSH access](/learn/kubevirt/vm-lifecycle-and-ssh-access/) — `testvm` running with SSH-key auth - Comfort reading basic Kubernetes Service YAML (ports, selector, type) Day-two networking questions for a KubeVirt VM all reduce to the same insight: a running VM is wrapped inside a pod. The networking primitives Kubernetes already gives you for pods — labels, Services, NetworkPolicies — apply directly. There’s almost nothing VM-specific to learn. Almost. ## Masquerade is NAT The default interface binding (and the one you’ve been using) is **masquerade**. The VM gets its own internal IP — typically something like `10.0.2.2` — and KubeVirt hides it behind NAT inside the virt-launcher pod. Outgoing traffic from the guest is source-NAT’d to the pod’s cluster IP. Incoming cluster traffic should target the pod, not the guest. Confirm by SSH’ing into the VM and comparing the two addresses: ```bash virtctl ssh -i ~/.ssh/id_ed25519 ubuntu@vmi/testvm # Inside the guest ip -4 addr show enp1s0 exit ``` Then look at the pod from the host side: ```bash kubectl get pod -l kubevirt.io/domain=testvm -o jsonpath='{.items[0].status.podIP}' ``` The guest’s internal address and the pod’s cluster IP are different — both real, both routable in their own contexts. The pod IP is what the rest of the cluster sees, so that’s what Services target. ## DNS and the outside world Because masquerade routes the guest through the pod network, the guest inherits the pod’s DNS configuration and gets cluster DNS plus internet reachability for free: ```bash virtctl ssh -i ~/.ssh/id_ed25519 ubuntu@vmi/testvm # Inside the guest sudo apt-get update # works; resolves archive.ubuntu.com via cluster DNS curl -sI https://kubernetes.io | head -1 nslookup kubernetes.default.svc.cluster.local exit ``` The first two work because the pod has internet egress; the third resolves the in-cluster Kubernetes API service the same way any pod would. Nothing VM-specific. ## Exposing a service running on the VM Run a tiny web server inside the guest so we have something to expose: ```bash virtctl ssh -i ~/.ssh/id_ed25519 ubuntu@vmi/testvm # Inside the guest sudo apt-get install -y nginx echo "Hello from testvm" | sudo tee /var/www/html/index.html exit ``` There are two ways to put a Service in front of it. **Way 1 — `virtctl expose`.** A shortcut that picks a sane label selector (`kubevirt.io/domain`) and creates a ClusterIP Service: ```bash virtctl expose vmi testvm --name=testvm-web --port=80 --target-port=80 kubectl get svc testvm-web ``` **Way 2 — write the Service yourself.** What `virtctl expose` does, but transparent: ```yaml apiVersion: v1 kind: Service metadata: name: testvm-web spec: selector: kubevirt.io/domain: testvm ports: - port: 80 targetPort: 80 type: ClusterIP ``` The selector matches the labels on the **virt-launcher pod**, because KubeVirt copies labels from `spec.template.metadata.labels` on the VM down to the VMI and on to the pod. From the Service’s perspective, the VM is a pod with a couple of unusual containers — the routing logic doesn’t care. Test from a debug pod: ```bash kubectl run -it --rm curl-debug --image=curlimages/curl --restart=Never -- \ curl -s testvm-web.$NS.svc.cluster.local ``` You’ll get back `Hello from testvm`. ## When to use which Service type The same three rules as any containerized workload: - **ClusterIP** — in-cluster only. Good for VM-to-VM and pod-to-VM traffic; what `virtctl expose` defaults to. - **NodePort** — opens a port on every node. Use sparingly, mostly for development. `kubectl expose vmi testvm --type=NodePort --port=80` if you want one quickly. - **LoadBalancer** — only useful if you have a controller that provisions external load balancers (cloud LB, MetalLB, KubeLB). On a managed cluster this is the production answer. On a sandbox it’ll sit in `Pending` until something fulfills the request. ## NetworkPolicies still apply Because the guest’s traffic flows through the virt-launcher pod, **standard Kubernetes NetworkPolicies select VMs the same way they select pods**. A `podSelector` matching `kubevirt.io/domain: testvm` covers the VM transparently. That means microsegmentation, namespace isolation, and egress controls all work — your existing policy tooling needs no extension to cover virtualized workloads. This is the underrated benefit of running VMs as pods. ## What’s next Networking handled. The next gap is durable state — every VM you’ve booted so far has been on an ephemeral container disk. The [storage tutorial](/learn/kubevirt/vm-storage-with-datavolumes/) attaches a real PersistentVolumeClaim, walks through CDI’s DataVolume importer, and covers the access-mode trap that bites teams when they get to live migration. #### Resources - [KubeVirt — Service objects for VMs](https://kubevirt.io/user-guide/network/service_objects/) - [KubeVirt — interfaces and networks](https://kubevirt.io/user-guide/network/interfaces_and_networks/) - [Kubernetes Services](https://kubernetes.io/docs/concepts/services-networking/service/) #### On This Page - [Masquerade is NAT](#masquerade-is-nat) - [DNS and the outside world](#dns-and-the-outside-world) - [Exposing a service running on the VM](#exposing-a-service-running-on-the-vm) - [When to use which Service type](#when-to-use-which-service-type) - [NetworkPolicies still apply](#networkpolicies-still-apply) - [What’s next](#whats-next) --- ## VM Storage with DataVolumes and CDI - **URL:** https://www.kubermatic.com/learn/kubevirt/vm-storage-with-datavolumes/ - **Date:** 2026-04-30 [Learn](/learn/) / [Kubevirt](/learn/kubevirt/) / VM Storage with DataVolumes and CDI kubevirt # VM Storage with DataVolumes and CDI ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Apr 27, 2026 4 min read Beginner [virtualization](/learn/?tag=virtualization) [storage](/learn/?tag=storage) [cdi](/learn/?tag=cdi) [datavolumes](/learn/?tag=datavolumes) #### Prerequisites - [VM networking with KubeVirt](/learn/kubevirt/vm-networking-with-kubevirt/) — `testvm` running - At least 10 GB of headroom in your default StorageClass Every VM you’ve booted so far has been ephemeral. The container disk image is read-only, runtime writes are held in memory, and everything you change disappears when the VMI restarts. That’s the right default for learning, and the wrong default for anything you want to keep. This tutorial fixes both: it attaches a PersistentVolumeClaim to `testvm` for durable state, and then boots a fresh VM directly from a real cloud image imported by CDI. ## containerDisk is not persistent Worth saying clearly because it bites people in production: a `containerDisk` is a disk image baked into an OCI container. The VM writes go into a writable layer in memory. Stop the VM, the writes are gone. Use containerDisks for stateless, immutable, throwaway workloads — the OS root for a build agent, a worker node base image, a quickly-provisioned scratch VM. Anything you’d hate to lose needs a PVC. ## Hotplug a PVC into the running VM Create a small PVC backed by your default StorageClass: ```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: testvm-data spec: accessModes: [ReadWriteOnce] resources: requests: storage: 5Gi ``` ```bash kubectl apply -f testvm-data-pvc.yaml kubectl get pvc testvm-data ``` Hotplug it into the running VM: ```bash virtctl addvolume testvm --volume-name=testvm-data ``` The guest sees a new block device appear (typically `/dev/vdb`) without a reboot — the kernel notices the same way it would notice a USB drive plugged into a real machine. SSH in, partition, format, mount, write something to verify: ```bash virtctl ssh -i ~/.ssh/id_ed25519 ubuntu@vmi/testvm # Inside the guest lsblk sudo mkfs.ext4 /dev/vdb sudo mkdir -p /mnt/data sudo mount /dev/vdb /mnt/data echo "persistent across reboots" | sudo tee /mnt/data/canary.txt sudo umount /mnt/data exit ``` Stop the VM and start it again. The PVC stays put; when you re-attach and remount, your file is still there. That’s the durability story KubeVirt inherits from Kubernetes’ storage primitives — without writing any virtualization-specific glue. ## Boot a fresh VM from a DataVolume Hotplug is right when you’re adding a data disk to an existing VM. For a VM that *boots* from a real cloud image (not the small containerDisk), you want a **DataVolume** as the root. A DataVolume is a PVC with superpowers. CDI’s DataVolume controller watches for them, creates a PVC under the hood, and runs an importer pod that downloads a cloud image from an HTTP URL (or a registry, an upload, an existing PVC clone, a `VolumeSnapshot`, etc.) into the PVC. When the importer reports `Succeeded`, the PVC is ready to boot from. Here’s a VM whose root disk is a DataVolume importing the official Ubuntu 22.04 cloud image: ```yaml apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: ubuntu-vm spec: runStrategy: Always dataVolumeTemplates: - metadata: name: ubuntu-vm-rootdisk spec: source: http: url: https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img storage: accessModes: [ReadWriteOnce] resources: requests: storage: 20Gi template: metadata: labels: kubevirt.io/domain: ubuntu-vm spec: domain: devices: disks: - name: rootdisk disk: bus: virtio - name: cloudinitdisk disk: bus: virtio interfaces: - name: default masquerade: {} resources: requests: memory: 2Gi cpu: "1" networks: - name: default pod: {} volumes: - name: rootdisk dataVolume: name: ubuntu-vm-rootdisk - name: cloudinitdisk cloudInitNoCloud: userData: | #cloud-config ssh_authorized_keys: - PASTE_YOUR_PUBLIC_KEY_HERE ``` Apply it and watch the import: ```bash kubectl apply -f ubuntu-vm.yaml kubectl get datavolume,pvc,vmi -l kubevirt.io/domain=ubuntu-vm -w ``` CDI walks through `WaitForFirstConsumer` → `ImportInProgress (with %)` → `Succeeded` (3–8 minutes for a ~600 MB image, depending on bandwidth). Once the DataVolume is ready, the VM boots and you can `virtctl ssh` in. ## The access mode trap The `accessModes: [ReadWriteOnce]` choice above works for a single-node VM and **prevents live migration**. RWO PVCs only allow one pod to mount them at a time, so KubeVirt can’t migrate the VM to another node without first stopping it. For a live-migratable VM, the StorageClass must support **`ReadWriteMany` (RWX)** and the DataVolume/PVC has to declare it. On a sandbox cluster running Longhorn, both modes are available — you pick one when you create the volume. On most cloud block-storage CSI drivers, only RWO is available; for RWX you need a file-storage driver (NFS, CephFS, EFS). This catches teams late in a project. Write your DataVolumes with the access mode you actually need from day one. If migration matters, RWX. If it doesn’t, RWO is cheaper and faster. ## What’s next Storage and migration are the foundation for everything operational — backups, HA, planned-maintenance drains. With a real DataVolume root and the right access mode, the rest of the operational story (live migration with `virtctl migrate`, snapshots via `VirtualMachineSnapshot`, backup integrations) is upstream KubeVirt territory and the user guide is the right next read. #### Resources - [KubeVirt — disks and volumes](https://kubevirt.io/user-guide/storage/disks_and_volumes/) - [KubeVirt — Containerized Data Importer (CDI)](https://kubevirt.io/user-guide/storage/containerized_data_importer/) - [KubeVirt — hotplug volumes](https://kubevirt.io/user-guide/storage/hotplug_volumes/) - [Kubernetes — volume access modes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes) #### On This Page - [containerDisk is not persistent](#containerdisk-is-not-persistent) - [Hotplug a PVC into the running VM](#hotplug-a-pvc-into-the-running-vm) - [Boot a fresh VM from a DataVolume](#boot-a-fresh-vm-from-a-datavolume) - [The access mode trap](#the-access-mode-trap) - [What’s next](#whats-next) --- ## Meet Kubermatic Virtualization 1.1 - Web UI, GitOps Installer & Advanced Networking - **URL:** https://www.kubermatic.com/blog/meet-kubermatic-virtualization-1-1-web-ui-gitops-installer-and-advanced-networking/ - **Date:** 2026-04-23 - **Description:** Kubermatic Virtualization 1.1 is live! Experience cloud-native virtualization with HA, live migration, and enterprise-ready automation, powered by Kubernetes. - **Categories:** Company - **Authors:** Moath Qasim We are proud to announce the release of Kubermatic Virtualization 1.1! KubeV 1.1 delivers a self-service virtualization platform with a web UI, built-in authentication, and flexible installation via both wizard and declarative workflows. ## Release Highlights of KubeV 1.1 ### Full Web UI (No kubectl needed) KubeV now ships a **complete, production-ready dashboard** to manage VMs, networking, and storage end-to-end through a clean UI. ### Declarative Installer (GitOps Ready) KubeV v1.1 combines an interactive wizard with a declarative, GitOps-ready workflow, allowing teams to choose between guided setup or automated, YAML-based configuration. With a single **kubermatic-virtualization apply** command, infrastructure can be installed, upgraded, and self-healed in a scalable and CI/CD-friendly way. ### Advanced Networking Made Simple KubeV v1.1 simplifies advanced networking by having full control over Kube-OVN (including multi-NIC and tunnel configuration) while enabling easy management of VPCs and subnets directly from the web UI. ### Built-in Authentication and Secure by Default Supports No Auth, Basic Auth, and OIDC/SSO — with optional in-cluster Dex installation for instant enterprise-grade login without external setup — and Ships with **Kyverno policies out of the box** to automatically enforce VM security best practices. ### Air-Gap & Enterprise Ready KubeV v1.1 is built for enterprise environments with full air-gap support, including image mirroring, OCI-based distribution of all components, and seamless offline installation. ## Get started today Kubermatic Virtualization 1.1 marks an important milestone in Kubermatic's mission to make **cloud-native infrastructure accessible and open**. Whether you're building a private cloud from scratch or modernizing your existing virtualization layer, Kubermatic Virtualization gives you the tools to run, protect, and scale your workloads on your terms. **Learn more and get started**: [visit the documentation](https://docs.kubermatic.com/kubermatic-virtualization/v1.1.0/) --- ## Giving AI Hands: How KDP Makes Infrastructure Agent-Ready - **URL:** https://www.kubermatic.com/blog/giving-ai-hands-how-kdp-makes-infrastructure-agent-ready/ - **Date:** 2026-04-30 - **Description:** Most AI assistants can tell you about your infrastructure but can't touch it. MCP and Skills change that — when paired with a platform like KDP that gives agents a unified, RBAC-bounded API surface. - **Categories:** Best Practices - **Tags:** KDP, Kubernetes - **Authors:** Julio Perez, Max Strübing Platform engineering has a growing problem: AI agents that can explain your infrastructure but can't operate on it. The bottleneck isn't the model. It's that most internal platforms were designed around humans clicking buttons, not around tools calling APIs. This post walks through how we approached that with the Kubermatic Developer Platform (KDP), and what we learned when we put MCP and Skills on top of it. ## Infrastructure at Most Companies Today If you've worked at any company with more than a few teams, you already know what infrastructure management looks like in practice. It's a dozen or even hundreds of systems scattered throughout the company. Team A has a Terraform module in a Git repo. Team B uses a self-service portal for namespaces but files Jira tickets for databases. Team C just asks in Slack and hopes someone on the platform team sees it. There's a Redis instance in staging that nobody is sure who owns. The "documentation" is a Confluence page from 2022 that links to a CLI tool that was deprecated last year. ![Teams tangled across Terraform, Jira, Slack, consoles, and a deprecated CLI — no single source of truth](/static/kdp-ai-agents-image6.png) This happens when every team solves their immediate needs with whatever they have. Over a couple years you end up with a patchwork of provisioning methods, access patterns, and knowledge that only lives in people's heads. And this is exactly why AI can't help with infrastructure today at most companies. You can't point an AI agent at this mess and expect it to figure out which Terraform module to run, which Slack channel to ask in, or which wiki page is still accurate. There's no unified interface. This is where KDP fits in. A unified platform creates the API surface that makes AI-assisted infrastructure management possible. One catalog to discover services. One API to provision them. One interface to check status and get credentials. When everything goes through the same surface, an AI agent with access to it can start being useful. ## MCP and Skills — Giving AI Hands Most AI assistants are stuck in a loop where they can tell you about how to run your infrastructure but can't actually touch it. You ask "what databases do we have running?" and get a generic answer about how to use `kubectl get`. Not really helpful. [Model Context Protocol](https://modelcontextprotocol.io/) fixes this. It's an open protocol, started at Anthropic, now under the Linux Foundation, that lets AI models call external tools. The model discovers what tools are available, figures out the parameters, and calls them when you ask for something. No custom integration per system. You run an MCP server that wraps your API, and any AI client that speaks MCP can use it. ![AI agent calls an MCP server over JSON-RPC; the server mediates access to infrastructure tools](/static/kdp-ai-agents-image1.png) There's a simpler option too: skills. In [Claude Code](https://docs.anthropic.com/en/docs/claude-code), a skill is just a markdown file that tells the agent how to do a specific job. No server, nothing to deploy. You write something like "when the user asks to enable a service, run these kubectl commands in this order, and don't mention APIBindings, just say you enabled it." Drop the file in a folder and the agent picks it up. ![MCP server versus Skill — two complementary ways to give an AI agent capabilities](/static/kdp-ai-agents-image2.png) Both have tradeoffs. MCP servers are more capable, they can maintain state, do complex logic, handle auth. Skills are simpler to write and share but limited to whatever commands you allow, and the combination can bring a better result sometimes. We built both for KDP, which we'll get to. MCP adoption has been fast, 97 million monthly SDK downloads as of early 2026, with support from Anthropic, OpenAI, Google, Microsoft, and yes, Kubermatic as a silver founding member of the Agentic AI Foundation ;) ## kcp — Kubernetes Without the Containers To understand KDP you need to understand [kcp](https://www.kcp.io/), because KDP is built on it. kcp takes the Kubernetes API machinery, the part where you declare what you want in YAML, apply it, and a controller reconciles it, and strips out everything specific to workloads. No Pods, no Deployments, no nodes. What's left is a generic multi-tenant API server that you can use to build platforms on. The central idea is workspaces. A workspace in kcp is a fully isolated environment, its own API endpoint, its own set of APIs, its own RBAC. It is like having your own Kubernetes cluster, except it's as cheap to create as a namespace. The project's ambition is a million workspaces across ten thousand shards, so the overhead per workspace is tiny. ![kcp workspace tree — root, organization workspaces, and team workspaces, each with its own APIs and RBAC](/static/kdp-ai-agents-image3.png) The part that matters for this blog post is what kcp calls "APIs as a Service." Any workspace can advertise and provide a service — an API. The API provider (workspace) publishes a set of resource types through an APIExport, essentially announcing, "I offer these APIs to anyone who wants them." A consumer in another workspace binds to that API by creating an APIBinding. Since all workspaces look like Kubernetes clusters, you can use kubectl to export, bind, and call the APIs! So simple. ![APIs sync from service clusters into the workspace where users consume them via APIExport and APIBinding](/static/kdp-ai-agents-image4.png) The simplicity of publishing and consuming services (APIs) is key to addressing platform engineering bottlenecks. The platform team does not need to be a guard for every interaction between teams. Second, we can bring necessary capabilities to development teams at the greatly increased speed enabled by AI. This is what we do in KDP, building on top of kcp. More at [docs.kcp.io](https://docs.kcp.io/) and [github.com/kcp-dev/kcp](https://github.com/kcp-dev/kcp). ## KDP — The Actual Platform [KDP](https://docs.kubermatic.com/developer-platform/) is what happens when you take kcp and build an Internal Developer Platform on top of it. It went GA in January 2026. The bottom line: developers shouldn't need to understand Kubernetes or kcp internals to get a database. They open a catalog, pick PostgreSQL, and have it running. All of kcp's multi-tenancy and API machinery, hidden behind something simple. Under the hood, there are three layers. The control plane is kcp. It manages workspaces, the service catalog, and isolation between tenants. This is where APIExports and APIBindings live, the mechanism that lets service providers publish and developers consume services. The sync layer is a lightweight agent called api-syncagent that runs on each service cluster. When a developer creates a PostgreSQL resource through KDP, the sync agent picks it up and syncs it over on the provider cluster (infrastructure side), creating an actual database on AWS, GCP, or wherever the service points to. The interface layer is a dashboard plus full kubectl. Anything you do in the UI, you can do through the API. This is important because it means automation and LLMs get the same capabilities as a human clicking through the dashboard. ![KDP's three layers: control plane (kcp), sync layer (api-syncagent), and service clusters across AWS, GCP, and on-prem](/static/kdp-ai-agents-image5.png) Three personas use KDP. Platform owners manage the installation and workspace hierarchy. Service providers run infrastructure and publish to the catalog, they do this on their own, without waiting for the platform team. Developers browse the catalog, enable what they need, and create resources. Full docs are at [docs.kubermatic.com/developer-platform](https://docs.kubermatic.com/developer-platform/). ## Enabling Agentic Workflows via KDP To cover agentic use cases, KDP provides: skills (a wrapper around kubectl and the kcp plugin), MCP, and skills for simplifying working with our MCP. We tested them on the same real-life scenario: finding and provisioning services for an app to run. The scenario: 1. We want a list of all available services and which databases we can use 2. Create a customer workspace with a production project inside with three active services (certificate management, databases and app engine) and create one of each and mount the database credentials into the app-engine 3. Delete the customer workspace When there was only the skill involved it worked great and without any issues but when the MCP was involved it forgot to accept the right permission claims so that the services are effectively unusable. We could have told the AI of course but the goal was to see what happens without much knowledge about the underlying system. There are for sure improvements we can make in our MCP implementation that would mitigate that problem, but I think the root cause here is that the AI did not combine the skill and MCP server but rather just used one. In fact we've tested it several times, the skill was always good. The skill including the MCP was right sometimes and the MCP server alone was always some kind of failure. ### KDP skill only (plus bare Kubernetes MCP) <iframe width="800" height="420" src="https://www.youtube.com/embed/uEDN0iFXeFI" title="KDP skill only (plus bare Kubernetes MCP)" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe> ### KDP MCP only (plus bare Kubernetes MCP) <iframe width="800" height="420" src="https://www.youtube.com/embed/dMmzfoOxDUc" title="KDP MCP only (plus bare Kubernetes MCP)" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe> ### KDP skill + KDP MCP (plus bare Kubernetes MCP) <iframe width="800" height="420" src="https://www.youtube.com/embed/gHGi8g4DSlw" title="KDP skill + KDP MCP (plus bare Kubernetes MCP)" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe> ## Safety and RBAC In recent talks around AI in the Infrastructure space, one of the first questions from the platform engineers is what stops it from doing something stupid. Fair question. The answer with KDP is that the AI agent goes through the exact same API and permission model as a human and its RBAC. There's no separate path. If a developer can't delete production databases from their workspace, neither can the AI agent operating in that workspace. kcp's workspace isolation and RBAC apply regardless of whether the request comes from someone clicking a button in the dashboard or an AI agent calling kubectl. This is one of the advantages of having a unified API surface. You don't need a separate permission system for AI. You scope the agent to a workspace, give it a kubeconfig with the right RBAC, and the guardrails are already there. And even for multi-workspace operations it is still constrained by your RBAC. On the MCP side, we get the KDP benefits and the extra of exposing only the tools it's programmed to, with JSON Schema validation on every argument. Skills are softer here, there's an *allowed-tools* field but it's more of a guardrail than a hard enforcement. The combination makes everything more powerful. KDP provides platform-level isolation, workspaces, RBAC, tenant boundaries. MCP provides the tool-level control. Together, you get an AI agent with security guardrails. ## Conclusion To match the velocity of AI development and the rise of autonomous agents, platform engineering must move toward a decentralized, API-first service model. KDP, powered by the **kcp** control plane, provides the machine-readable foundation required for both human developers and AI agents to interact with infrastructure programmatically. Because KDP uses standard Kubernetes APIs, is extensible, and is purpose-built for API orchestration, it is agent-ready. This allows AI agents to independently discover capabilities, manage complex dependencies, and execute service compositions without human intervention or manual gatekeeping. By treating infrastructure as composable artifacts, KDP removes the platform team from the critical path, enabling a marketplace where the speed of delivery is limited only by the speed of the agent's logic. This ensures that the platform remains a force multiplier for both traditional "Golden Path" applications and the next generation of agentic workflows. --- ## kcp v0.31: Kubernetes 1.35 Rebase, Cross-Shard Identity, and a Load Testing Framework - **URL:** https://www.kubermatic.com/blog/kcp-v0-31-release/ - **Date:** 2026-04-30 - **Description:** kcp v0.31.0 ships with a Kubernetes 1.35 rebase, cross-shard service account validation, an extractable Virtual Workspace framework, and a clusterloader2-inspired load testing framework. Coordinated release across kcp, kcp-operator, api-syncagent, multicluster-provider, and init-agent. - **Categories:** Best Practices - **Tags:** KDP, Kubernetes - **Authors:** Abubakar Siddiq Ango The kcp community shipped [v0.31.0](https://github.com/kcp-dev/kcp/releases/tag/v0.31.0) on April 13. This was a coordinated release: [kcp-operator (v0.7.0)](https://github.com/kcp-dev/kcp-operator/releases/tag/v0.7.0), [api-syncagent (v0.6.0)](https://github.com/kcp-dev/api-syncagent/releases/tag/v0.6.0), [multicluster-provider (v0.6.0)](https://github.com/kcp-dev/multicluster-provider/releases/tag/v0.6.0), [init-agent (v0.3.0)](https://github.com/kcp-dev/init-agent/releases/tag/v0.3.0), and updated Helm charts all shipped the same week. It's a substantial release that touches the foundation (Kubernetes 1.35 rebase), addresses a long-standing operational limitation (cross-shard service accounts), and lays groundwork for external extensibility and performance validation. Here's what changed and why it matters. ## Kubernetes 1.35.1 Rebase kcp now tracks [Kubernetes 1.35.1](https://github.com/kubernetes/kubernetes/releases/tag/v1.35.1) with [Go 1.25.7](https://go.dev/doc/devel/release#go1.25). This is not a simple version bump. A Kubernetes rebase in kcp touches the entire codebase: API types, generated clients, admission plugins, controller behavior, and test fixtures all need to adapt. The fact that the community keeps pace with upstream Kubernetes releases is what makes kcp a credible foundation for production platforms. For operators, this means kcp workspaces now behave consistently with Kubernetes 1.35 semantics, including any new API fields, admission changes, and deprecation removals that came with the upstream release. ## Cross-Shard Service Account Lookup Until now, service account validation in kcp was limited to the shard where the account was created. If a controller on shard A needed to authenticate with a service account from shard B, it would fail. This was a real operational limitation for anyone running multi-shard deployments. v0.31 introduces a TTL-based cache that enables service account validation across shard boundaries. The `GlobalServiceAccount` feature gate has been removed because the capability is now always on. This is a quiet but significant change: it removes a class of authentication failures that made multi-shard topologies harder to operate. ## APIResourceSchema Virtual Workspace A new Virtual Workspace type gives API providers access to the APIResourceSchemas of consumer workspaces. This is particularly relevant for the [kube-bind](https://github.com/kcp-dev/kube-bind) integration, where a provider needs to understand the schema of the resources it is serving to consumers. In practical terms, if you are building a service that exposes APIs to multiple kcp workspaces, you can now inspect and react to the schemas your consumers are using, without requiring direct access to their workspaces. ## Virtual Workspace Framework Extraction The Virtual Workspace framework (`pkg/virtual/framework` and `pkg/virtual/options`) has been moved to a dedicated staging repository. This is an architectural change aimed at external developers: if you are building a custom Virtual Workspace, you no longer need to vendor the entire kcp codebase. You can import just the framework. This reduces the dependency footprint for external VW projects and makes it easier for the ecosystem to build on kcp's extensibility model without tracking kcp's full dependency tree. ## Load Testing Framework kcp now has a load testing framework inspired by Kubernetes' clusterloader2. It supports scenario definitions (e.g., "create 10,000 empty workspaces"), P99 latency statistics, and structured reporting. The framework ships with three components: a scenario runner, a metrics collector, and a report generator. For the project, this is about proving that kcp's multi-tenant architecture scales. For operators evaluating kcp, it means the project now has a way to publish reproducible performance benchmarks, not just anecdotal claims. ## Security and Data Integrity Fixes Two critical fixes deserve attention: **Etcd key poisoning.** Unresolved workspace paths could corrupt etcd keys with malformed cluster names. This is a data integrity issue: once a bad key lands in etcd, it can affect lookups for other workspaces. Fixed in v0.31. **Virtual Workspace proxy impersonation isolation.** A concurrency issue caused impersonation headers to leak between requests in the VW proxy. In a multi-tenant system, impersonation header leakage means one request could briefly carry the identity of another. This has been resolved with per-request isolation. Both fixes are the kind of issue that matters most in production multi-tenant environments where data isolation and identity integrity are non-negotiable. Several dependency updates also address published CVEs: - [CVE-2026-33186](https://nvd.nist.gov/vuln/detail/CVE-2026-33186): google.golang.org/grpc - [CVE-2026-24051](https://nvd.nist.gov/vuln/detail/CVE-2026-24051): go.opentelemetry.io/otel/sdk - [CVE-2026-34986](https://nvd.nist.gov/vuln/detail/CVE-2026-34986): go-jose upgraded to v3.0.5 - [CVE-2026-39883](https://nvd.nist.gov/vuln/detail/CVE-2026-39883): OpenTelemetry SDK updated to 1.43.0 ## API and CLI Improvements The `kcp` CLI gains `claims accept` and `claims reject` subcommands, along with `--accept-all-permission-claims` and `--reject-all-permission-claims` flags. This makes PermissionClaim management scriptable, which is important for automation workflows where API bindings need to be approved or denied programmatically. On the API side, a new `defaultSelector` field on `PermissionClaim` in `APIExport` lets providers specify default permission claim selectors that are automatically applied when `APIBindings` are created via `WorkspaceType`. This reduces the manual configuration needed when onboarding consumers to an API export. Also worth noting: parallel resource installation during startup reduces cold-start time by approximately 5 seconds, and container image size has been reduced by roughly 25% through stripped debugging symbols. ## Ecosystem Releases The v0.31 release is coordinated across the kcp ecosystem. Here's what shipped alongside the core: ### [kcp-operator v0.7.0](https://github.com/kcp-dev/kcp-operator/releases/tag/v0.7.0) - Support for `topologySpreadConstraints` for better pod distribution - Multi-replica CacheServer deployments for scalability - Initial support for external Virtual Workspaces - CEL validation for Virtual Workspace configuration - Go 1.26.2, gRPC CVE fix ### [api-syncagent v0.6.0](https://github.com/kcp-dev/api-syncagent/releases/tag/v0.6.0) - Watch and sync changes to related resources (not just primary objects) - Fix cleanup of related resources on primary object deletion - Fix APIResourceSchema agent annotations and labels - Security updates for OpenTelemetry SDK CVEs and gRPC CVE ### [multicluster-provider v0.6.0](https://github.com/kcp-dev/multicluster-provider/releases/tag/v0.6.0) - Fix for factory managing multiple providers - Fix WildcardCache.Start with multiple Providers - Cluster filter and ready-only APIBinding engagement - Separate client module for cleaner dependency management - Adapted to multicluster-runtime v0.23.3 ClusterName type change ### [init-agent v0.3.0](https://github.com/kcp-dev/init-agent/releases/tag/v0.3.0) - Virtual Workspace URL path support in `--config-workspace` - Support for multiple `InitTargets` for the same `WorkspaceType` ### [Helm Charts](https://github.com/kcp-dev/helm-charts) All corresponding charts updated. The `proxy`, `shard`, `certificates`, and `cache` charts are now deprecated in favor of the kcp-operator. ## Deprecations - `--external-hostname` flag: now determined automatically from `--shard-base-url` or `--bind-address` - `--shard-external-url` flag for Virtual Workspaces: marked unused - Legacy `MachineAnnotations` API: removed - Helm charts for proxy, shard, certificates, and cache: deprecated, use kcp-operator instead ## Getting Started - [kcp GitHub repository](https://github.com/kcp-dev/kcp) - [v0.31.0 release notes](https://github.com/kcp-dev/kcp/releases/tag/v0.31.0) - [kcp documentation](https://docs.kcp.io/) - [kcp-operator v0.7.0](https://github.com/kcp-dev/kcp-operator/releases/tag/v0.7.0) - [api-syncagent v0.6.0](https://github.com/kcp-dev/api-syncagent/releases/tag/v0.6.0) - [multicluster-provider v0.6.0](https://github.com/kcp-dev/multicluster-provider/releases/tag/v0.6.0) - [init-agent v0.3.0](https://github.com/kcp-dev/init-agent/releases/tag/v0.3.0) ## Contributors Thanks to everyone who contributed to kcp v0.31.0 across the core, operator, syncagent, multicluster-provider, and init-agent repositories. The coordinated release reflects a maturing project with a growing contributor base. If you want to get involved, the [kcp-dev GitHub organization](https://github.com/kcp-dev) is the place to start. Join `#kcp-dev` on [Kubernetes Slack](https://slack.k8s.io/) to connect with the community. ## Build Your Internal Developer Platform on kcp with KDP kcp is powerful, but turning it into a production platform takes work: workspace lifecycle management, API publishing workflows, identity integration, day-2 operations, and the glue that makes it usable for your developers. That's exactly what the [Kubermatic Developer Platform (KDP)](https://www.kubermatic.com/products/kubermatic-developer-platform/) is built for. KDP is a fully managed internal developer platform built on kcp, designed to give platform teams a productized path from zero to a multi-tenant, API-driven developer experience, without having to assemble and operate the stack yourself. With KDP you get: - **Multi-tenant workspaces** with role-based access and policy guardrails - **API publishing and consumption** patterns built on kcp's APIExport/APIBinding model - **Day-2 operations**, upgrades, backups, observability, and multi-shard scaling handled for you - **Enterprise support** from the team that contributes to kcp upstream If you are evaluating kcp for an internal developer platform, [talk to us](https://www.kubermatic.com/products/kubermatic-developer-platform/). --- ## 10 Years of Kubermatic - **URL:** https://www.kubermatic.com/blog/10-years-of-kubermatic/ - **Date:** 2026-04-30 - **Description:** Kubermatic turns 10! From two founders to a global cloud-native company, here’s a look back at the moments, people, and community that shaped the journey. - **Categories:** Company - **Tags:** Announcements - **Authors:** Mirabella Fernandez Today, Kubermatic officially turns 10 years old. We are incredibly happy to share this milestone with you. What a journey so far. Looking back at the last decade, there are a few highlights to celebrate, especially around our community, partners, and team. ## How it all started Our story didn't start in a polished office with a fancy espresso machine. It started on a few long cycling trips. Back in early 2016, Sebastian Scheele and Julian Hansert were pedaling through the countryside, talking about a vague gut feeling that Kubernetes was going to be the next big thing, and sharing a sense that infrastructure didn't have to be this complicated. They didn't wait for someone else to build it. Our founders registered the company (which many of you remember as Loodse) and turned Julian's living room into our first office. At the time, "cloud-native infrastructure" wasn't exactly a buzzword. Most conversations started with explaining why containers mattered. Why Kubernetes wasn't just hype. Why automation could (and would) change everything. The early days involved a lot of explaining: what containers are, why Kubernetes matters, and why automation isn't just a "nice to have." It took time, patience, and a few people willing to take a chance on something that wasn't widely adopted yet. ## First steps We launched the first version of what would become our platform, based on the idea that companies wouldn't just run one cluster: they'd run many. We became one of the first Kubernetes Certified Service Providers and Training Partners, back when the ecosystem was still small and close-knit. From there, things moved quickly. We open-sourced our tools, changed our name (and made life easier for everyone who had to say "Loodse"), raised funding, and built new products. At the same time, we watched the ecosystem grow into something much bigger than it was in those early days. Meanwhile, we organized ContainerDays in Hamburg, bringing together a few hundred container enthusiasts, which felt huge at the time! (For context: KubeCon Europe had around 400 attendees that year). ## Milestones & story We've had some incredible moments along the way: **2016**: We hosted the first ContainerDays in Hamburg. We were nervous, but 200 people showed up, at a time when the biggest Kubernetes conferences only had a few hundred more. **2018**: We became one of the first 20 Kubernetes Certified Service Providers (KCSP) globally, part of a small and tight-knit group of pioneers. **2019**: We open-sourced KubeOne, our Kubernetes lifecycle management tool for automating deployment and operations of single clusters. **2020**: We open-sourced our core software (KKP) and officially became Kubermatic (no more trying to explain how to pronounce "Loodse"). **2023**: Kubermatic was recognized as one of the five Cool Vendors in Gartner's Cool Vendors in Container Management report. We also won the ECN Award in the category "Euro Cloud Native Member of the Year." **2024**: We launched KubeLB, our load balancer solution, and Kubermatic Virtualization, enabling you to build and manage your private cloud entirely with Kubernetes. **2025**: Kubermatic was recognized in the Gartner® Magic Quadrant™ and The Forrester Wave™, a moment that reflects how far the original vision has come. ## The people It's easy to list milestones. But that's not what stands out most when we look back. It's the people. From two founders in a living room to a team spread across 14 countries. Fully remote, long before it became the norm. Different backgrounds, cultures, and time zones. And not just internally. The community around us has been just as much a part of this journey. From organizing ContainerDays to speaking at conferences around the world, this ecosystem has always been about learning and building together. Back when Kubernetes events were small enough that you recognized most faces in the room, those conversations helped shape how we think about what we build today. That hasn't changed. Contributing to open source, hosting events, and sharing knowledge is core to how we operate. As one of Europe's top committers to the Kubernetes Project, we believe open source communities build better software for everyone. We actively contribute to upstream Kubernetes, cloud native technologies, and other projects that support multicloud adoption. A lot of what we've built wouldn't exist without that exchange of ideas, and that's still one of the best parts of this space. ## To Our Partners and Customers: Thank You We wouldn't be here without the 100+ customers and countless partners who have trusted us over the last ten years. You've challenged us, supported us, and helped us grow into the company we are today. As the saying goes: "Success isn't just about what you accomplish; it's about what you inspire others to do". We're proud of the last 10 years, and even more excited for what's next. Thank you for being part of our story. ## Watch the recap video {{< youtube "https://www.youtube.com/embed/aWvuX3U4KTA" >}} --- ## Kubermatic officially turns 10! - **URL:** https://www.kubermatic.com/resources/10-years-of-kubermatic/ - **Date:** 2026-04-14 - **Description:** A decade of building, contributing to open source, and growing with our community. # Kubermatic officially turns 10! ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video Celebrate 10 years of Kubermatic through the voices of the people who made it what it is today. In this video, we look back at a decade of building, learning, and growing, from the early days of an idea sparked on cycling trips to becoming a globally distributed, cloud-native company. But more than milestones, this story is about the people behind Kubermatic. Featuring short interviews with team members, this video highlights the culture, community, and shared passion that have shaped the company over the years. [Read the post](/blog/10-years-of-kubermatic/) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Meet KubeOne 1.13 - Supporting Kubernetes 1.35 - **URL:** https://www.kubermatic.com/blog/meet-kubeone-1-13-supporting-kubernetes-1-35/ - **Date:** 2026-04-30 - **Description:** KubeOne 1.13 introduces support for Kubernetes 1.35, containerd 2.2, enhanced security features, improved etcd management, and expanded authentication capabilities. - **Categories:** Products - **Tags:** KubeOne - **Authors:** Artiom Diomin We are proud to announce the release of **KubeOne 1.13**! KubeOne is our open-source cluster lifecycle management tool that helps you automate the deployment, upgrading, and management of Kubernetes clusters. With this release, we're continuing our commitment to stability, flexibility, and support for the latest innovations in the Kubernetes ecosystem. ## Release Highlights of KubeOne 1.13 This release brings a mix of new features, upgrades, and operational improvements designed to make cluster management even more robust and customizable. ### Support for Kubernetes 1.35 We've added [support for Kubernetes 1.35](https://github.com/kubermatic/kubeone/pull/3973), ensuring you can take advantage of the latest upstream features, performance improvements, and security enhancements. As always, all core components and add-ons are updated to maintain full compatibility. ### Container Runtime Upgrade KubeOne now [upgrades **containerd** from v1.7.x to v2.2.x](https://github.com/kubermatic/kubeone/pull/4006), bringing improved performance, stability, and better alignment with modern Kubernetes requirements. ### Enhanced Admission Controller Support We've expanded support for key admission plugins: - [Added **EventRateLimit**](https://github.com/kubermatic/kubeone/pull/4029https://github.com/kubermatic/kubeone/pull/4029) admission plugin support - [Added **AlwaysPullImages**](https://github.com/kubermatic/kubeone/pull/4027) plugin wiring across kubeadm configs and API server arguments - Enabled [**NodeRestriction** admission](https://github.com/kubermatic/kubeone/pull/4012) plugin by default These enhancements improve cluster security and governance out of the box. ### Improved etcd Management Managing etcd is now easier than ever: - Added new configuration options - [Introduced operational commands](https://github.com/kubermatic/kubeone/pull/3998) via `kubeone etcd` This gives operators more control over one of the most critical components in a Kubernetes cluster. ### Networking Enhancements - Added `enable-l2-announcements` [configuration option for **Cilium CNI**](https://github.com/kubermatic/kubeone/pull/3991), improving flexibility in networking setups ### Registry & Helm Authentication - [Added registry authentication support](https://github.com/kubermatic/kubeone/pull/4014) for both source registries and mirror hosts - [Added authentication support](https://github.com/kubermatic/kubeone/pull/3922) in **HelmRelease** These updates simplify working with private registries and secured Helm deployments. ### Storage Improvements - `Enabled allowVolumeExpansion` for [Cinder CSI](https://github.com/kubermatic/kubeone/pull/4001) storage classes, allowing dynamic volume resizing ### Platform Flexibility - [Added option to skip **aznfs**](https://github.com/kubermatic/kubeone/pull/3949) package installation on Azure - [Updated install script](https://github.com/kubermatic/kubeone/pull/3914) to support **ARM architectures** on Linux and macOS ### Configuration & Validation Changes - [Removed validation](https://github.com/kubermatic/kubeone/pull/3993) enforcing mutual exclusivity between ContainerdRegistry and RegistryConfiguration - [Removed resource limits](https://github.com/kubermatic/kubeone/pull/3979) from machine-controller and OSM components for improved flexibility ## Get Started with KubeOne 1.13 Today! - **Check out the release on** [GitHub](https://github.com/kubermatic/kubeone) and give us a star! ;) - **Read the docs**: Go through the detailed [changelog](https://github.com/kubermatic/kubeone/releases) and [documentation](https://docs.kubermatic.com/kubeone/v1.13/) for specific configuration guides. We can't wait to see what you build with Kubeone 1.13! --- ## Predicts 2026: Container Management Becomes an AI Enabler - **URL:** https://www.kubermatic.com/predicts-2026-container-management-becomes-ai-enabler/ - **Date:** 2026-07-07 - **Description:** Discover Gartner's® Predicts 2026: Container Management Becomes an AI Enabler # “– By 2028, more than 20% of enterprises will initiate container management initiatives to specifically support AI deployments, up from approximately 5% today.” Gartner® Predicts 2026: Container Management Becomes an AI Enabler ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Complimentary Gartner® ## Predicts 2026: Container Management Becomes an AI Enabler Published 03 Feb 2026 [Download the Report](/predicts-2026-container-management-becomes-ai-enabler/#report) ![Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-img.png) As generative AI pivots from initial exploration to delivering tangible business value, infrastructure leaders are facing a critical turning point. According to Gartner latest report, Kubernetes and container technologies have officially emerged as the foundational engines for orchestrating complex AI inference workloads and navigating strict digital sovereignty demands. However, scaling these highly dynamic environments introduces massive cloud financial challenges, particularly when managing unpredictable traffic spikes and expensive compute hardware like GPUs. To succeed in this new era, enterprises must quickly bridge the gap between elastic scalability and rigorous FinOps practices. As Gartner predicts, "**By 2030, companies that fail to optimize the underlying costs of AI infrastructure will pay more than 50% more than those that do**." Download the full report to discover actionable recommendations for aligning your container strategies with AI initiatives, securing digital autonomy, and implementing the cost-optimization frameworks necessary to prevent significant monetary waste. If our form couldn't load correctly – This can have multiple reasons like ad blocker, not accepted cookies, JavaScript deactivated. However, you can still get in touch with us! Simply click on the button below, and you'll be able to submit the form and reach out to us for any inquiries or assistance you need. [Open form](https://share.hsforms.com/1oc1uhWj3TM2mCZsCamsWwA2piu8) * * * ***Gartner, Predicts 2026: Container Management Becomes an AI Enabler, 03 February 2026*** ***GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.*** ## Our Upcoming Events [![Proud partner of WeAreDevelopers World Congress Europe, 8-10 July, Berlin](/static/event-wearedevelopers26_hu_1cbbc2a6515d782.jpg)](https://www.wearedevelopers.com/) Onsite Conference ## [Join us in Berlin at WeAreDevelopers](https://www.wearedevelopers.com/) [Join Here](https://www.wearedevelopers.com/) [![](/static/containerdays-hamburg-2026_hu_d4a7201e201462bf.jpg)](https://www.containerdays.io/containerdays-hamburg-2026/) Onsite Conference ## [ContainerDays Hamburg is Back in the Harbor of Hamburg for 2026!](https://www.containerdays.io/containerdays-hamburg-2026/) [Join Here](https://www.containerdays.io/containerdays-hamburg-2026/) ## Ready to try Kubermatic Kubernetes Platform? [Get Your Free Demo](/demo/) --- ## Swisscom's Journey from Vendor Lock-In to Cloud Native Infrastructure Platform - **URL:** https://www.kubermatic.com/customers/swisscoms-journey-from-vendor-lock-in-to-cloud-native-infrastructure-platform/ - **Date:** 2026-06-23 - **Description:** Discover how Swisscom transitioned to a CNCF-certified, cloud-native infrastructure with Kubermatic, delivering a sovereign Kubernetes service that ensures 100% Swiss data residency. # Swisscom’s Journey from Vendor Lock-In to Cloud Native Infrastructure Platform ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## The Challenge ### Moving Beyond Legacy Constraints As a premier Swiss service provider, Swisscom envisioned evolving its existing “Container Service” into a next-generation platform. The goal was clear: create a modern, powerful, and flexible Kubernetes offering for its private cloud customers that would guarantee data sovereignty and give Swisscom full control over quality and reliability. Achieving this vision, however, required overcoming significant challenges. The legacy solution’s reliance on proprietary VMware technology created high costs and stifled innovation through vendor lock-in. Furthermore, a modernization gap had emerged, as competing with global hyperscalers meant delivering advanced features like autoscaling and native load balancing. Layered on top of these technical requirements were strict sovereignty demands to meet rigorous Swiss data protection laws. Finally, the sheer operational complexity of building a multi-tenant, highly available platform from scratch demanded a streamlined and highly automated approach to management. ## The Solution ### Automating Complexity with an Open-Source Core To solve these challenges, Swisscom architected its new Kubernetes Service as an entirely new, highly available platform grounded in open-source technologies. *"**In collaboration with Kubermatic, a leading Kubernetes platform provider, we eliminated proprietary technology and have established a robust foundation**,"* states Christian Dietrich, Product Manager for Cloud at Swisscom. The core of this new foundation is the Kubermatic Kubernetes Platform (KKP), which provides the powerful provisioning and orchestration engine for all backend services. Leveraging a full open-source stack built on KKP with Baremetal, KubeVirt, and Kube-OVN, Swisscom was empowered to deliver a truly modern and flexible service. KKP’s automation was key to managing the full cluster lifecycle, including updates and autoscaling across two regions and three availability zones. This enabled Swisscom to offer the advanced, CNCF-certified feature set their customers demanded, including flexible CNI options, enhanced RBAC security, and a native Kubernetes Load Balancer, ensuring the highest standards in cloud-native technology. ## The Impact ### Achieving Sovereignty, Control, and a Competitive Edge The launch of the new Kubernetes Service, powered by Kubermatic, has had a profound impact on both Swisscom and its customers. For Swisscom, replacing its proprietary stack with an open-source solution built on KKP has eliminated vendor lock-in, providing full control over their technology roadmap while dramatically lowering licensing costs. This shift enables them to offer a more competitive and cost-effective service. Consequently, Swisscom’s customers now benefit from a truly sovereign and compliant platform, with all infrastructure, operations, and support contained exclusively within Switzerland. They receive a modern, feature-rich, and intuitive self-service experience that rivals the performance of global hyperscalers, ultimately accelerating their own digital transformation journeys. Check out the [Swisscom documentation](https://docs.cloud.swisscom.ch/guide/cloud-services/kubernetes-service/structure/) for a deep dive into the architecture. ![Optical fibers](/static/swisscoms-journey-from-vendor-lock-in-to-cloud-native-infrastructure-platform-bg.jpg) ![Swisscom white logo](/static/swisscom-white.svg) Swisscom is the leading ICT company in Switzerland and, with Fastweb + Vodafone, the strong #2 in the Italian market. The company offers mobile, Internet and TV, as well as comprehensive IT and digital services to private and business customers. Swisscom is the most sustainable telecommunications company in the world and is 51% owned by the Swiss Confederation. Swisscom successfully launched its new Kubernetes Service, a completely re-architected, CNCF-certified platform for its Private Cloud users. By partnering with Kubermatic and building on the Kubermatic Kubernetes Platform (KKP), Swisscom was able to eliminate proprietary technology, reduce costs, and deliver a feature-rich, sovereign cloud-native solution that rivals the offerings of leading global hyperscalers. --- ## How Kubermatic enabled Swisscom to launch a Sovereign Kubernetes Service - **URL:** https://www.kubermatic.com/blog/how-kubermatic-enabled-swisscom-to-launch-a-sovereign-kubernetes-service/ - **Date:** 2026-04-30 - **Description:** Learn how Swisscom worked with Kubermatic to launch a sovereign Kubernetes service with 100% Swiss data residency and no vendor lock-in. - **Categories:** Company - **Tags:** Announcements - **Authors:** Sebastian Scheele Every established tech company eventually faces a crossroads: do you stick with the stable but restrictive legacy platform you know, or do you take the leap to build a modern, open-source future? This is the story of how Swisscom, a premier Swiss service provider, didn't just face that decision; they mastered it. ## The Vision: A Sovereign Cloud for Switzerland As a leader in a nation with some of the world's most stringent data protection laws, Swisscom has always been committed to delivering innovative, enterprise-grade technology. Their existing "Container Service" was functional, but they envisioned something more for their private cloud customers: a true next-generation platform. The goal was ambitious but clear: create a modern, powerful, and flexible Kubernetes service that could guarantee data sovereignty while giving Swisscom full control over the quality and reliability of their own offerings. ## Dependencies and Complexity Achieving this vision meant confronting several significant challenges: - **Strict Data Sovereignty**: The platform had to be engineered from the ground up to meet rigorous Swiss data protection laws, with all operations contained within Switzerland. - **Modernization Gap**: To compete with global hyperscalers, the new service needed advanced features like autoscaling, native load balancing, and faster Kubernetes updates. - **Reduced vendor reliance**: The new solution should provide maximum technological freedom and eliminate any form of dependency, enabling us to shape our roadmap autonomously. - **Operational Complexity**: Building a new, multi-tenant Kubernetes platform from scratch required a highly automated approach to management. ## A New Foundation Built on Open Source and Kubermatic Instead of an incremental update, Swisscom made a bold choice: to architect an entirely new, highly available platform from the ground up, grounded in open-source technologies and cloud-native principles. This is where the collaboration with Kubermatic began. *"**Together with Kubermatic, a leading Kubernetes platform provider, we have established a robust and future-ready foundation based on open-source technologies,**"* states Christian Dietrich, Product Manager for Cloud Services at Swisscom. The core of this new foundation is the Kubermatic Kubernetes Platform (KKP). It provides the powerful orchestration and automation engine that enabled Swisscom to: - **Automate the full cluster lifecycle**, from provisioning to updates and autoscaling across multiple regions. - **Deliver a rich, CNCF-certified feature set**, including flexible networking (CNI), enhanced security (RBAC), and a native Kubernetes Load Balancer. - **Build on a 100% open-source stack**, empowering them with a truly modern and flexible service. ## A Win-Win for Swisscom and Its Customers The launch of the new Kubernetes Service, powered by Kubermatic, represents a significant step forward in strengthening Swisscom’s technological foundation and expanding future capabilities. This advancement introduces a modern, cloud native stack that lowers technical dependencies, provides full architectural flexibility and greater autonomy over their technology roadmap. This shift allows them to offer a more competitive and innovative service. Consequently, their customers are the ultimate beneficiaries. They now have access to a sovereign and compliant Kubernetes platform, with all infrastructure and support contained exclusively within Switzerland. They get a modern, feature-rich, and intuitive self-service experience and performance comparable to leading global cloud providers, ultimately accelerating their own digital transformation journeys. This collaboration is more than just a technical success; it's a blueprint for building a modern, sovereign cloud future without compromise. ## About Swisscom Swisscom is the leading ICT company in Switzerland and, with Fastweb + Vodafone, the strong #2 in the Italian market. The company offers mobile, Internet and TV, as well as comprehensive IT and digital services to private and business customers. Swisscom is the most sustainable telecommunications company in the world and is 51% owned by the Swiss Confederation. Swisscom successfully launched its new Kubernetes Service, a completely re-architected, CNCF-certified platform for its Private Cloud users. Built in partnership with Kubermatic and powered by the Kubermatic Kubernetes Platform (KKP), the service establishes a modern, open and flexible technological foundation that enhances efficiency, expands architectural freedom, and supports continued innovation. The result is a feature rich, sovereign and cloud native solution that stands on par with the capabilities of leading global hyperscalers. --- ## KubeCon EU 2026 Recap - Agents, Sovereignty, and the Rules of the Road - **URL:** https://www.kubermatic.com/blog/kubecon-eu-2026-recap/ - **Date:** 2026-04-30 - **Description:** KubeCon EU 2026 in Amsterdam surfaced five trends shaping cloud native; agentic infrastructure via MCP, European sovereign cloud adoption, the EU Cyber Resilience Act, GPU scheduling standar dization, and platform engineering maturation. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Abubakar Siddiq Ango [KubeCon + CloudNativeCon Europe 2026](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/) wrapped up in Amsterdam on March 26. Over 10,000 engineers, 15 co-located events, and hundreds of sessions across five days. We were there all week at Booth #820, and our team presented across multiple tracks. Here's what mattered, what surprised us, and what you should be paying attention to over the next 12 months. ## The Future of Cloud Native Is Agentic The thesis was serious: cloud native is moving from containers and microservices to autonomous agents that compose tools, call APIs, and act on infrastructure. This wasn't confined to the AI+ML track. MCP (Model Context Protocol, [donated to the Linux Foundation](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation) in December 2025) appeared in sessions across every track. [Akuity and Intuit presented](https://kccnceu2026.sched.com/event/2EIbg/the-10x-devops-engineers-toolkit-argo-cd-+-ai-driven-mcp-automation-alexander-matyushentsev-akuity-leonardo-luz-almeida-intuit) an open source MCP server for Argo CD enabling agent-driven rollbacks and multi-environment coordination. [Linkerd presented MCP](https://kccnceu2026.sched.com/event/2EFyE/project-lightning-talk-mcp-routing-in-linkerd-flynn-technical-evangelist) routing support, making it the first service mesh to detect MCP servers and manage routing at the tool and resource level. The CNCF created an entirely new co-located event for this: [Agentics Day](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/co-located-events/agentics-day-mcp-agents/), a full half-day dedicated to MCP and AI agents on Kubernetes. When CNCF creates a dedicated event for something, it's no longer experimental. It's the next primitive. But the hard problem isn't running agents. It's governing them. Session after session tackled the same questions: How do you authorize an agent? How do you give it a stable identity? How do you stop it from acting outside its intended scope when it has access to your production API? The [OWASP MCP Top 10](https://owasp.org/www-project-mcp-top-10/) is already published. "Shadow MCP" (developers deploying unmanaged MCP servers on laptops to connect AI assistants to production databases) was flagged as a [real and present security risk](https://aquilax.ai/blog/mcp-security-shadow-ai-agents). Solo.io's [agentgateway](https://agentgateway.dev/) and [kagent](https://kagent.dev/) emerged as infrastructure primitives for governing agent-to-tool communication. Our take: MCP is at the HTTP moment. The protocol is settling. The identity, authorization, and audit layers don't exist yet. The teams that build those layers will define how agents operate on infrastructure for the next decade. ## Europe Is Building, Not Buying The sovereignty narrative went from theoretical to production-proven at this KubeCon. Three co-located events reflected this: Open Sovereign Cloud Day, Platform Engineering Day (now two tracks, full day), and Cloud Native Telco Day. The keynotes told the story through case studies: - **SNCF** (France's national railway) presented [running 200+ clusters](https://kccnceu2026.sched.com/event/2CtKn/keynote-keeping-sovereignty-on-track-kubernetes-powering-a-national-railway-platform-thomas-comtet-senior-staff-engineer-sncf-yann-rotilio-senior-staff-engineer-kubernetes-specialist-sncf) across Azure and AWS, with a private cloud on OpenStack + Kubernetes for sovereign control. - **Saxo Bank** keynoted on ["Digital Sovereignty by Design"](https://kccnceu2026.sched.com/event/2I17q/keynote-digital-sovereignty-by-design-turning-developer-intent-into-portable-enterprise-scale-automation-oskar-kristiansen-enterprise-platform-engineer-saxo-bank), sharing how Kubernetes operators + GitOps delivered 1,800 automated operations, reducing provisioning from weeks to minutes. - **BWI** (German federal IT) presented on [building a sovereign multi-cloud strategy](https://kccnceu2026.sched.com/event/2HgHb/keynote-building-a-sovereign-multi-cloud-strategy-with-cloud-native-technologies-goetz-reinhaeckel-program-director-cloud-bwi) with cloud native technologies. - **Swisscom** published its full sovereign Kubernetes architecture as a [CNCF reference architecture](https://architecture.cncf.io/architectures/swisscom-kubernetes-service/), the first of its kind on architecture.cncf.io. Built on KubeOne, KKP, KubeVirt, Kyverno, and ArgoCD, Swisscom migrated 60% of internal workloads within nine months of launch. The pattern is clear. European regulated enterprises (telcos, banks, railways, defense) are assembling sovereign platforms from CNCF open-source components rather than buying from hyperscalers. The recipe is converging: KubeVirt for VMs, Kyverno for policy, ArgoCD for GitOps, KubeOne for cluster lifecycle, KKP for multi-tenant management. The driver isn't ideology. It's jurisdiction. Under the US CLOUD Act, American authorities can compel US providers to disclose data stored anywhere in the world. Swiss, German, and French institutions are building independent stacks to stay outside that reach. We wrote more about the Swisscom architecture in [our newsletter deep dive](/blog/the-control-plane-issue-2-kubecon-debrief/). ## The CRA Changes the Rules Greg Kroah-Hartman, lead maintainer of the Linux stable branch, [took the keynote stage](https://tfir.io/linux-remains-the-foundation-powering-kubernetes-revolution-greg-kroah-hartman/) to explain what the EU Cyber Resilience Act means for open source. The timeline is concrete: - **September 11, 2026**: Mandatory vulnerability reporting begins for manufacturers and [Open Source Stewards](https://openssf.org/public-policy/eu-cyber-resilience-act/) (foundations like CNCF and Linux Foundation). - **December 11, 2027**: Full enforcement of all CRA requirements, including CE marking and conformity assessments. Individual open source contributors are explicitly exempt. The CRA targets companies shipping products and foundations providing ongoing support for projects. Kroah-Hartman argued the CRA correctly places responsibility on the companies shipping products, not the maintainers who write the code. His advice for sustainable open source was "enlightened self-interest": companies should contribute to solve their own problems (sovereignty, compliance), which benefits the broader community. The CRA doesn't just affect compliance teams. SBOM (Software Bill of Materials) generation is becoming a legal requirement, and as the "SBOOM" session revealed, current open-source tools frequently generate conflicting package lists for the same container image. The tooling needs to catch up to the regulation. Kyverno's [graduation](https://www.cncf.io/announcements/2026/03/24/cloud-native-computing-foundation-announces-kyvernos-graduation/) to a CNCF graduated project during KubeCon week was well-timed. Policy engines aren't optional in a CRA world. ## GPU Infrastructure Is Industrializing Dynamic Resource Allocation (DRA) went GA in Kubernetes 1.34, and KubeCon 2026 was the vendor adoption wave. NVIDIA and Google [donated their respective GPU and TPU DRA drivers](https://blogs.nvidia.com/blog/nvidia-at-kubecon-2026/) to the CNCF, establishing Kubernetes as the neutral AI infrastructure control plane. The conversation moved well past "can Kubernetes schedule GPUs?" into production optimization: - [Kueue](https://kueue.sigs.k8s.io/) for gang scheduling (ensuring all pods in a distributed training job get GPUs simultaneously, or none do) - Volcano's [AgentCube](https://www.cncf.io/blog/2026/03/23/beyond-batch-volcano-evolves-into-the-ai-native-unified-scheduling-platform/) for serverless agent sandboxes with millisecond startup via WarmPools - [CoHDI](https://github.com/CoHDI) (CNCF Sandbox) for cross-cluster GPU lending via DRA - [Slinky](https://github.com/slinkyproject) (Google + SchedMD) bridging Slurm and Kubernetes scheduling, signaling HPC convergence Jonathan Bryce, CNCF Executive Director, framed the stakes in [his keynote](https://siliconangle.com/2026/03/24/kubecon-europe-2026-ai-execution-gap-meets-cloud-native-reality/): 82% Kubernetes adoption, but only 7% deploy AI to production daily. He argued that optimizing for open models could unlock $24.8 billion in annual global AI savings. ## Platform Engineering: Architecture, Not Tooling Platform Engineering Day ran two tracks all day. The conversation has decisively shifted from "should we build a platform?" to "why isn't our platform being adopted?" Abby Bangser from Syntasso [keynoted on Thursday](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/program/keynote-speakers/) with a thesis that stuck. When platform engineering fails, the problem is architectural, not about effort or tooling. Netlify CEO Mathias Biilmann introduced [Agent Experience (AX)](https://biilmann.blog/articles/introducing-ax/) as a framework for designing platforms where agents are first-class consumers alongside humans. The scale numbers from other talks were staggering: - Airbnb: 1,000 services migrated with zero downtime, 5-person team - Walmart: 5,000 edge clusters, 5-minute deploys - Allianz: 1,000+ Kubernetes control planes - DigitalOcean: 20,000+ clusters managed by 4 engineers The [CNCF Platform Engineering Maturity Model v2](https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/) was released during the conference, marking the transition from portal-centric thinking to industrialized backend orchestration. ## Kubermatic at KubeCon EU 2026 Here's what we presented: Marvin Beckers presented the **kcp CVE-2025-29922 deep dive** in the Security track (stepping in for Marko Mudrinic, who was ill). A full public walkthrough of how a virtual workspace isolation flaw in kcp was initially scored as Medium, then reclassified to [CVSS 9.6 Critical](https://github.com/advisories/GHSA-w2rr-38wv-8rrp) when the true blast radius became clear. Responsible disclosure at its best: discover, report, patch, disclose, then educate publicly at the biggest conference in the ecosystem. **Koray Oksay** delivered [Beyond Match & Pattern: Mastering Kyverno with CEL](https://colocatedeventseu2026.sched.com/event/2DY9j/beyond-match-pattern-mastering-kyverno-with-cel-koray-oksay), a lightning talk. showing how CEL (Common Expression Language) unlocks dynamic, context-aware logic in Kyverno policies. From validation conditions to preconditions and match logic, CEL enables cleaner, smarter policies for security, governance, and multi-tenant control that go beyond boilerplate YAML. **Mario Fahlandt** presented three times across the week: - **SIG Contributor Experience** panel on guiding contributors through the project, alongside engineers from Broadcom and SUSE - **TAG Operational Resilience** session on sustainability release guidelines - **Advancing Kubernetes AI Conformance** session on the [Certified Kubernetes AI Conformance Program](https://www.cncf.io/announcements/2025/11/11/cncf-launches-certified-kubernetes-ai-conformance-program-to-standardize-ai-workloads-on-kubernetes/), defining what "AI-ready" means for a Kubernetes platform **Karol Szwaj** led the **kcp Contribfest**, a hands-on session guiding first-time contributors from zero to their first pull request alongside Nelo-T. Wallus from SAP. ## Five Trends for the Next 18 Months If we had to distill the week into durable signals: 1. **Agents are the new microservices.** MCP is the protocol. Kubernetes is the runtime. Authorization is the unsolved problem. Every platform team needs an agentic strategy. 2. **Sovereignty is an architecture, not a contract.** European enterprises are building independent stacks from CNCF components. The recipe is converging. The question is no longer "is it technically viable?" but "who builds next?" 3. **The CRA changes how we maintain open source.** Documentation, vulnerability handling, and SBOM generation aren't optional anymore. September 2026 is six months away. 4. **GPU scheduling is standardizing.** DRA is GA. NVIDIA and Google donated drivers. Kueue is the job scheduler. The "artisanal GPU management" era is ending. 5. **Platform engineering is a governance problem.** The tools are mature. Backstage, Crossplane, GitOps, self-service blueprints. The missing piece is organizational authority backed by architectural enforcement. Amsterdam was a good week. The cloud native ecosystem just got a lot more serious about running AI safely, governing infrastructure for Europe, and building platforms that actually get adopted. See you at KubeCon North America in Salt Lake City. --- ## About Us - **URL:** https://www.kubermatic.com/company/about-kubermatic/ - **Date:** 2026-07-07 - **Description:** Kubermatic is a German enterprise Kubernetes company founded in 2016 that provides automated hybrid and multi-cloud container management platforms. Recognised in the 2025 Gartner® Magic Quadrant™ and Forrester Wave™ for container management, Kubermatic serves enterprises in defence, telecom, manufacturing, and public sector. # About Kubermatic Kubermatic is a German enterprise software company headquartered in Hamburg, founded in 2016. The company builds automated Kubernetes management platforms that help enterprises operate container workloads across hybrid cloud, multi-cloud, edge, and on-premises environments. Kubermatic is recognised in the 2025 Gartner® Magic Quadrant™ for Container Management, named in the Forrester Wave™: Multicloud Container Platforms Q3 2025, and is ISO 27001 and ISO 9001 certified. [Contact Sales](/contact-sales/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## What Does Kubermatic Do? **What does Kubermatic do?** Kubermatic automates the deployment, management, and operation of Kubernetes clusters across any infrastructure: public cloud (AWS, Azure, GCP), private cloud, bare metal, and edge. Its platform reduces manual operations for enterprise infrastructure teams, enabling organisations to run hundreds of Kubernetes clusters from a single control plane. **What is Kubermatic’s mission?** Kubermatic’s mission is to give every organisation, regardless of size or technical maturity, the ability to fully automate their cloud native operations. The company builds open-source-rooted tooling so enterprises can innovate without being locked into a single cloud provider. **What industries does Kubermatic serve?** Kubermatic serves regulated and complex industries including defence, public sector, manufacturing, and telecommunications. Its sovereign infrastructure capabilities make it a preferred choice for European enterprises with strict data residency and security requirements. ![Company gathering photo](/static/people-at-kubermatic.jpg) ## How Did Kubermatic Start? In early 2016, Kubermatic (or Loodse back then) was not much more than two guys with a gut feeling that Kubernetes could potentially be a big thing, and the ambition to build a business model around that. After discussing this rather vague idea on several cycling trips, Kubermatic founders Julian Hansert, COO and Sebastian Scheele, CEO didn’t hesitate for very long, registered the company, and turned Julian’s living room into the first office. What followed thereafter can only be described as a crazy rollercoaster ride that sometimes left us a little dizzy. **Kubermatic founding facts:** - Founded: April 2016, Hamburg, Germany (originally as Loodse GmbH) - Founders: Sebastian Scheele (CEO) and Julian Hansert (COO) - First product: Kubermatic Kubernetes Platform (KKP) beta, launched February 2017 - Open-sourced KKP: June 2020 (company rebranded from Loodse to Kubermatic at same time) - Seed funding: $8.3M raised November 2021, led by Nauta Capital and btov Partners - Headquarters: Hamburg, Germany ![Conversation between Sebastian and Julian](/static/picture-of-founders.jpg) ## Kubermatic Milestones and Recognition ![Kubermatic 10th Anniversary](/static/kubermatic-10th-anniversary-1480x680.png) ## 2026 ### April Kubermatic officially turns 10! A decade of building, contributing to open source, and growing with our community. We're proud of what we've achieved, and excited for what's next. ### July Kubermatic gets recognized as a Leader in the SPARK Matrix™ for Edge Kubernetes Platforms. ![Kubermatic Named in Gartner® Magic Quadrant™ and recognized in The Forrester Wave™](/static/kubermatic-named-in-gartner-magic-quadrant-and-recognized-in-the-forrester-wave.png) ## 2025 ### July Kubermatic recognized as one of the 9 top vendors in The Forrester Wave™: Multicloud Container Platforms, Q3 2025. Forrester, a leading independent research firm, evaluated the most significant providers against 31 criteria, and we believe this recognition places us among a select group shaping the future of Kubernetes management. ### August Kubermatic named in the 2025 Gartner® Magic Quadrant™ and recognized in the Critical Capabilities for Container Management! ![Kubermatic Wins 2025 Digital Innovator Award from Intellyx](/static/digital-innovator-award-from-intellyx.png) ## 2025 ### June Kubermatic Wins 2025 Digital Innovator Award from Intellyx. As Intellyx celebrates 11 years of championing digital transformation, this award recognizes companies that are making bold strides in reshaping the enterprise technology landscape, and we're honored to be among them. ![Some members of the Kubermatic team](/static/some-members-of-the-kubermatic-team.jpg) ## 2024 ### March After months of development, we proudly launch KubeLB, our ultimate Load Balancer solution. ### October The Big Day arrives and we introduce the world to Kubermatic Virtualization, allowing you to build and manage your private cloud entirely with Kubernetes. ### November And to finish this year with a bang, we launch our internal developer platform: Kubermatic Developer Platform. Designed to make life easier for Developers, KDP automates repetitive tasks, freeing up Developers' time to do what they do best. ![Year 2023](/static/kubermatic-is-winner-of-ecn-award-2023.jpg) ## 2023 ### August Kubermatic recognized as one of the five 'Cool Vendors' in the August 2023 report by Gartner titled 'Cool Vendors in Container Management'. Kubermatic is the only European vendor to be recognized in the August 2023 report by Gartner titled 'Cool Vendors in Container Management'. ### September Kubermatic is the winner of the ECN Award 2023 in the category "Euro Cloud Native Member of the Year". ![Year 2021](/static/2021-milestone.jpg) ## 2021 ### November Investment announcement! We raise a total of $8.3M in Seed Funding, led by Nauta Capital and followed by btov Partners. ![Year 2020](/static/2020-milestone.jpg) ## 2020 ### June BIG BANG!!! We open source our core software KKP and change the name of the company from Loodse to Kubermatic. (After four years of trying to explain how to pronounce “Loodse”, we decided to give up). ![Year 2019](/static/2019-milestone.jpg) ## 2019 ### May We open source KubeOne, our Kubernetes lifecycle management tool, which automates deployment and operations for single Kubernetes clusters. ### June Kubermatic joins the MELLODDY consortium. ![Year 2018](/static/2018-milestone.jpg) ## 2018 ### May Kubermatic becomes one of the first twenty Kubernetes Certified Service Providers (KCP) and Kubernetes Training Partners (KTP). Just three years later, the cloud native landscape lists 200 KCPs and 50 KTPs. ![Year 2017](/static/2017-milestone.jpg) ## 2017 ### February Convinced that organizations would get to a point where they would adopt multiple, rather than single Kubernetes clusters, we launch the beta version of Kubermatic Kubernetes Platform (KKP). ### May We receive the German Accelerator Tech award for exceptionally promising tech startups. ![Year 2016](/static/2016-milestone.jpg) ## 2016 ### April Founding ### June We organize the first ContainerDays (CDS) conference with more than 200 container enthusiasts in Hamburg harbor. (At the time, these numbers were very exciting, considering that KubeCon Europe had about 400 participants that year. Looking at CDS’s participation numbers today, it’s truly amazing how much this event has grown.) ## Frequently Asked Questions ### What is Kubermatic? Kubermatic is an enterprise Kubernetes management company headquartered in Hamburg, Germany. It provides software platforms and professional services that help organisations deploy, automate, and operate Kubernetes clusters across hybrid cloud, multi-cloud, edge, and on-premises infrastructure. ### Is Kubermatic open source? Yes. Kubermatic’s core platform, Kubermatic Kubernetes Platform (KKP), was open-sourced in June 2020. Kubermatic also maintains KubeOne, an open-source Kubernetes lifecycle management tool, and contributes actively to the Cloud Native Computing Foundation (CNCF) ecosystem. ### Where is Kubermatic based? Kubermatic GmbH is headquartered in Hamburg, Germany. The company is a German-founded enterprise with a European-first approach to data sovereignty and regulatory compliance. ### Is Kubermatic listed in Gartner's Magic Quadrant? Yes. Kubermatic was named in the 2025 Gartner® Magic Quadrant™ for Container Management and recognised in the Critical Capabilities report. It was also named a Gartner Cool Vendor in 2023, the only European vendor to receive that recognition. ### What does Kubermatic's Kubernetes Platform do? Kubermatic Kubernetes Platform (KKP) enables enterprises to create, manage, and automate hundreds of Kubernetes clusters from a single control plane. It supports major cloud providers (AWS, Azure, GCP), on-premises environments (VMware vSphere, Nutanix, OpenStack), bare metal, and edge deployments. ### Who are Kubermatic's founders? Kubermatic was founded in 2016 by Sebastian Scheele (CEO) and Julian Hansert (COO), who started the company in Hamburg after recognising early that Kubernetes would become a foundational enterprise infrastructure technology. ### What certifications does Kubermatic hold? Kubermatic is ISO 27001 (Information Security) and ISO 9001 (Quality Management) certified. It is a Kubernetes Certified Service Provider (KCSP) and Kubernetes Training Partner (KTP), among the first 20 companies globally to achieve KCSP status in 2018. Last updated: July 2026 --- ## Control Plane Newsletter - Issue 2 - **URL:** https://www.kubermatic.com/blog/the-control-plane-issue-2-kubecon-debrief/ - **Date:** 2026-04-30 - **Description:** The Control Plane Issue 2 - What KubeCon EU 2026 told us about the next 12 months of cloud native infrastructure. - **Categories:** Best Practices - **Tags:** Kubernetes, Newsletter - **Authors:** Abubakar Siddiq Ango KubeCon EU 2026 just wrapped in Amsterdam. 10,000+ engineers, 15 co-located events, and three themes that dominated every hallway conversation: agentic infrastructure, sovereign cloud, and the EU Cyber Resilience Act. [Issue #2](https://kubermatic-4550048.hs-sites.com/the-control-plane-2-kubecon-debrief-agents-sovereignty-the-cra-swisscom-built-a-sovereign-cloud-in-9-months-kcps-cvss-9.6-wake-up-call) of The Control Plane breaks down what matters and what you can ignore. ## How Swisscom Built a Sovereign Kubernetes Platform in 9 Months The CNCF published Swisscom's sovereign Kubernetes stack as an [official reference architecture](https://architecture.cncf.io/architectures/swisscom-kubernetes-service/). It's the first peer-reviewed blueprint proving a full sovereign cloud can run on open-source components, no hyperscaler required. In the deep dive, we walk through the full architecture: KubeOne for cluster lifecycle management, KubeVirt for VM-as-a-Pod virtualization, KKP for multi-tenant cluster provisioning, Kyverno for policy guardrails, and the custom "glue" operators Swisscom built to make it all work. We also cover why Swiss data protection law (nFADP) made automated guardrails a legal necessity, not just good engineering. ## Also in this issue - **MCP is the new API.** Anthropic's Model Context Protocol showed up in sessions across every track at KubeCon. Argo CD, Linkerd, Flux, OpenCost, and Lima all announced MCP support. We cover the adoption wave and why "Shadow MCP" is already in the OWASP Top 10. - **War Story: When a "Medium" CVE becomes CVSS 9.6 Critical.** A vulnerability in kcp's virtual workspace isolation was initially scored as Medium. Then the maintainers realized a single compromised tenant could take over every other workspace. - **Kubermatic Releases.** KKP v2.30.0 ships with Kubernetes 1.35 support, a GPU Machine Type Selector, and full Gateway API support. kcp v0.30.1 rebases on Kubernetes 1.34.2 with cross-workspace ValidatingAdmissionPolicy. KubeLB v1.3.5 adds WAF support and an Ingress-to-Gateway API migration tool. - **Control Plane Radar.** Curated reads on the CRA enforcement timeline, DRA going GA for GPU scheduling, the Swisscom CLOUD Act analysis, and the contrarian case against European sovereignty. ## Subscribe The Control Plane ships once a month. No spam. <script charset="utf-8" type="text/javascript" src="//js.hsforms.net/forms/embed/v2.js"></script> <script> hbspt.forms.create({ portalId: "4550048", formId: "774d7fa4-cb63-4643-ab4d-008fbde3e744", region: "na1" }); </script> --- ## Introducing Kubermatic SecureGuard: Open, Kubernetes-Native Secrets Management - **URL:** https://www.kubermatic.com/blog/introducing-secureguard/ - **Date:** 2026-04-30 - **Description:** Meet Kubermatic SecureGuard, a new open-source secrets management platform built on OpenBao and ESO. - **Categories:** Company - **Tags:** KubeSG, Announcements - **Authors:** Gergely Bräutigam Today, we are excited to introduce a new open-source secrets management platform for Kubernetes and cloud-native environments: **[Kubermatic SecureGuard (KubeSG)](/products/kubermatic-secureguard/)**. ## Why we created Kubermatic SecureGuard Every modern platform runs on secrets: API keys, database credentials, certificates, and tokens. They unlock production systems, customer data, and AI workloads, but they are also one of the most common ways into your infrastructure. As organizations scale, secrets often become fragmented across clusters, tools, and environments. And while **72% of teams say secrets management helps prevent breaches, more than half still do not have a secure solution in place**. Nearly **one in four developers has already experienced a breach caused by compromised credentials**. We believe managing secrets should be simple, transparent, and native to Kubernetes. Teams should focus on shipping workloads, not on tickets and manual rotations. ## What is Kubermatic SecureGuard? KubeSG is a self-hosted, open-source secrets management platform built on [OpenBao](https://openbao.org/) and integrated with the [External Secrets Operator (ESO)](https://external-secrets.io/latest/). It lets security teams define access rules in one central place while applications receive only the secrets they need, directly inside their environments. This keeps access secure while making it easier for teams to work with secrets as part of their normal Kubernetes workflows. Kubermatic SecureGuard is built entirely on open-source components and maintained in the open. Its security model is transparent, auditable, and free from restrictive licensing. ## How Kubermatic SecureGuard works KubeSG brings a few smart tools together to make secrets easy to manage. Its OpenBao Core keeps secrets encrypted and logs every access. Using ESO, secrets are synced straight into Kubernetes, so developers can work with standard Secret objects without learning new tools. Passwords and API keys rotate automatically without restarting applications, and the system handles startup and lifecycle management across clouds. KubeSG also supports multiple vaults and storage backends, letting teams use the tools that fit their environment. ## Reach out to us! [Get in touch with us](/demo/) to know all about Kubermatic SecureGuard. To keep in the loop about what is happening, keep an eye on the [Kubermatic GitHub repository](https://github.com/kubermatic) and join the {{< slackjoinlink "Kubermatic community Slack" >}}. We're planning many exciting features! --- ## Portal vs Platform, Why Your IDP Needs More Than a Catalog - **URL:** https://www.kubermatic.com/blog/portal-vs-platform/ - **Date:** 2026-04-30 - **Description:** Most IDP initiatives stall because teams build portals when they need platforms. A portal catalogs services. A platform provisions them. This post breaks down the difference and what your IDP actually needs. - **Categories:** Products - **Tags:** KDP - **Authors:** Abubakar Siddiq Ango Platform engineering has moved past the buzzword phase. Most software organizations now have dedicated platform teams, and the tooling has caught up. But a growing number of these initiatives are stalling, not because the tools are bad, but because teams are solving the wrong problem. They're building portals when they need platforms. ## The portal wave got one thing right The first generation of Internal Developer Platforms focused on a real problem: developers couldn't find anything. Services were scattered across wikis, Slack threads, and tribal knowledge. Backstage, the open-source framework created by Spotify and now a CNCF project, addressed this head-on with a centralized service catalog and plugin ecosystem. And it worked for discovery. Backstage remains the most widely adopted developer portal framework, with a community ecosystem of over 200 plugins covering everything from Kubernetes to CI/CD. Port followed with a no-code approach that let platform teams model their engineering topology without writing TypeScript. Cortex focused on engineering standards and scorecards. Each brought something valuable to the table. That first wave proved that developer experience matters, that discoverability reduces cognitive load, and that a single pane of glass beats scattered documentation. But here's where most of them stop. ## The last-mile problem A developer finds a database service in the catalog. They click on it. And then... they open a Jira ticket. Or message someone on Slack. Or wait for a pull request to be reviewed in a GitOps repo they don't have access to. This is what industry analysts now call the "[portal trap](https://platformengineering.org/blog/the-biggest-challenges-platform-engineering-teams-are-facing-in-2026)": investing heavily in a front door that leads to the same manual provisioning workflows that existed before. The catalog looks great. The developer experience ends at the catalog. The [2026 platform engineering survey](https://platformengineering.org/blog/the-biggest-challenges-platform-engineering-teams-are-facing-in-2026) reflects this gap. 45% of platform engineering teams say developer adoption is their primary challenge, and nearly a third don't measure success at all. The most common reason? The platform doesn't actually do anything. It shows you what exists but can't create what you need. Backstage is particularly susceptible to this pattern because it's a framework, not a finished product. Making it production-ready requires dedicated engineering effort. Estimates from [Roadie](https://roadie.io/blog/7-best-developer-portals-for-enterprise-engineering-teams/) and [independent analyses](https://tasrieit.com/blog/port-vs-backstage-vs-cortex-developer-portal-comparison-2026) range from three to twelve engineers depending on scale, with ongoing maintenance for version upgrades, security patches, and plugin compatibility. For organizations with 500+ engineers and a well-resourced platform team, this investment can pay off. For everyone else, it often becomes the platform team's own maintenance burden rather than a force multiplier. ## Portal versus platform: the distinction that matters The industry has started drawing a clear line between two concepts that were previously conflated: A **developer portal** is the interface layer: catalog, documentation, visibility, and discovery. It answers "what do we have?" A **developer platform** is the engine underneath: provisioning, multi-tenancy, service lifecycle, and automation. It answers "what can I get, right now, without asking anyone?" The most effective platform engineering organizations treat these as separate architectural layers. The portal is the front door. The platform is the building behind it. You need both, but building only the front door and calling it a platform is why initiatives fail. This isn't a theoretical distinction. It shows up in concrete ways: - **Provisioning:** Can a developer request a database and get one in seconds, or do they file a ticket? - **Multi-tenancy:** Are teams isolated at the workspace level, or are they sharing namespaces with RBAC rules and hoping for the best? - **Service lifecycle:** Does the platform manage updates, deprecation, and resource cleanup, or is that someone's manual job? - **Extensibility:** Can service owners plug in their own offerings, or is everything centrally managed by the platform team? Humanitec recognized this gap early and built a "Platform Orchestrator," a backend engine that dynamically generates environment-specific configurations. Both Humanitec and tools like Kratix (from Syntasso, which takes a Kubernetes-native Promise-based approach) acknowledge that the portal layer isn't enough. ## What a platform actually needs If a portal is a catalog, a platform is an operating system for developer services. It needs: **A provisioning engine.** Not a link to Terraform docs. Actual, automated provisioning that turns a developer's request into a running resource. This means integration with infrastructure tools like Crossplane, Terraform, or cloud-native operators, abstracted behind a simple interface. **Real multi-tenancy.** Namespace-level isolation with RBAC rules is the Kubernetes equivalent of putting tape down the middle of a shared desk. It works until it doesn't. A real platform provides workspace-level or cluster-level isolation where teams operate independently without stepping on each other. **A service catalog that provisions, not just lists.** The catalog should be the interface through which developers actually create resources, not a directory that links to a runbook. **API-native architecture.** Platform teams already know Kubernetes. A platform that requires learning a proprietary SDK, a new specification language, or a framework-specific plugin system adds cognitive load rather than reducing it. The best platforms work with the tools teams already use. ## The AI dimension: platforms as agentic infrastructure AI agents are already changing what platforms need to do. These systems plan and execute multi-step workflows on their own. They need to discover available services, provision resources, and manage lifecycle, all programmatically. This changes what we need from a platform in three ways: **Agents need APIs, not dashboards.** A human can navigate a portal UI. An AI agent needs clean, well-documented, machine-readable APIs. Platforms built on standard Kubernetes APIs are inherently agent-ready. Every operation accessible via `kubectl` is also accessible to any tool that speaks the Kubernetes API. **AI-assisted provisioning lowers the barrier.** When a platform can accept a natural language description ("I need a PostgreSQL database with 100GB storage for my analytics team") and generate the correct resource specification, the Kubernetes expertise barrier drops significantly. This isn't replacing engineers; it's making the platform accessible to a broader set of users. **AI workload management requires platform-level governance.** As organizations deploy AI models internally, they need to control which teams access which models, manage compute allocation, and enforce compliance boundaries. A platform with proper multi-tenancy and RBAC becomes the governance layer for AI infrastructure. Teams order a model, get an endpoint, and the platform handles isolation and access control. The platforms that will matter in the agentic era aren't the ones with the prettiest dashboards. They're the ones with the most composable, API-driven architecture. ## Where KDP fits Kubermatic Developer Platform (KDP) was built with this portal-vs-platform distinction in mind. Rather than starting with a UI and working backward, KDP started with the infrastructure layer and worked up. KDP makes it easy to expose day-2 data to consumers, encouraging ownership and resolving the broken ownership problem. **Built on kcp, a CNCF Sandbox project.** KDP's foundation is open source and community-governed. kcp provides lightweight logical Kubernetes clusters called workspaces, each one a separate API server with full isolation at the control plane level, without the cost and complexity of spinning up full clusters. Actual workloads still run on service clusters managed by service providers, but tenants are completely invisible to each other at the API layer. This is multi-tenancy that goes beyond namespaces and RBAC rules. **Kubernetes APIs all the way down.** There is no proprietary CLI and no TypeScript plugins to write. Service owners do work with KDP-specific custom resources like `PublishedResource` to define what they expose, but these are standard Kubernetes CRDs, not a new framework or specification language. Every operation in KDP, from browsing the service catalog to provisioning a database, works through standard Kubernetes APIs. If your team knows `kubectl`, they know KDP. **A service catalog that actually provisions.** When a developer selects a service from the KDP catalog, they get a running resource, not a ticket. Service owners connect their clusters to KDP through the api-syncagent, a lightweight connector that handles bidirectional sync between the central control plane and distributed service clusters. Crossplane integration is built in, so cloud resources from AWS, GCP, or Azure can be exposed through the same catalog without custom glue code. **AI-native capabilities.** KDP includes an AI assistant built into the dashboard. Developers describe what they need in plain language, and the assistant generates a valid Kubernetes resource manifest. Server-side schema validation catches errors before submission. But the AI story goes deeper than developer assistance. KDP's API-driven, multi-tenant architecture with standardized service interfaces makes it a natural governance layer for AI infrastructure itself. Platform teams can control model access per workspace, manage GPU compute boundaries, and provide self-service AI model provisioning through the same catalog that handles databases and storage. When your teams need access to an LLM endpoint, they request it from the catalog like any other service. The platform handles isolation, RBAC, and resource allocation. **Designed for service owners, not just consumers.** Most portals are built for developers consuming services. KDP is equally built for the teams providing them. Service owners manage their own clusters and decide what to publish to the platform. The central platform team doesn't become the bottleneck for every new service. **Complements portals, doesn't replace them.** If your organization has already invested in Backstage or Port as a developer-facing UI, KDP doesn't ask you to throw that away. KDP operates at the platform layer: the provisioning, multi-tenancy, and service lifecycle engine that sits behind whatever portal your developers prefer. The portal is the front door; KDP is the building. ## Questions to ask when evaluating your IDP Whether you're building, buying, or somewhere in between, these questions cut through the marketing: 1. **Does it provision, or does it just catalog?** If a developer still files a ticket after finding a service, you have a portal, not a platform. 2. **What does multi-tenancy actually mean?** Namespace + RBAC is not the same as workspace-level isolation. Ask how teams are separated and what happens when one team's misconfiguration could affect another. 3. **What APIs does it expose?** Proprietary APIs mean vendor lock-in and integration overhead. Kubernetes-native APIs mean your existing tools, scripts, and automation work on day one. 4. **Who maintains it?** A framework you self-host means your platform team spends time maintaining the platform instead of building golden paths. A managed solution shifts that burden but may limit customization. 5. **Is it agent-ready?** As AI-driven automation becomes standard, your platform needs machine-readable APIs and programmatic access to everything. If it only works through a UI, it has an expiration date. 6. **Can service owners self-serve?** If adding a new service to the platform requires the central team to build a plugin or write integration code, the platform team becomes the bottleneck. That's the exact problem you were trying to solve. The IDP market has matured enough that "we need a developer portal" is no longer a sufficient strategy. The question now is whether you're building a front door or the building behind it. --- ## What Is KDP? A Developer's Guide to Kubermatic Developer Platform - **URL:** https://www.kubermatic.com/blog/what-is-kdp/ - **Date:** 2026-04-30 - **Description:** KDP is an Internal Developer Platform built on kcp that replaces ticket-based provisioning with self-service. Developers browse a service catalog and get running resources in seconds, no tickets, no waiting, no Kubernetes expertise required. - **Categories:** Products - **Tags:** KDP - **Authors:** Abubakar Siddiq Ango Your platform team built a service catalog. Developers can browse it, find what they need, and then... file a ticket. Two days later, they get their database. Three days if it's a Friday. This is the gap that Internal Developer Platforms are supposed to close. And for many organizations, the gap is still wide open. [Kubermatic Developer Platform](https://kubermatic.com/products/kubermatic-developer-platform) (KDP) is an Internal Developer Platform built to close it, from the infrastructure up, not the UI down. It is built on [kcp](https://www.kubermatic.com/kcp/), a CNCF Sandbox project that Kubermatic actively maintains. It gives platform teams a Kubernetes-native control plane with a service catalog that actually provisions resources, workspace-level isolation, and AI-assisted service creation. KDP went GA in January 2026. This guide covers what KDP does, how it works, and who it's built for. ## The problem KDP solves Platform engineering exists because developers shouldn't need to understand infrastructure to ship software. But most organizations are stuck somewhere between "we have a wiki" and "we have a portal that links to a wiki." The typical experience looks like this: - A developer needs a PostgreSQL database for a new service - They search an internal wiki, Slack, or a service catalog - They find the request process: a Jira ticket, a Terraform PR, or a message to the platform team - They wait hours or days for provisioning - They repeat this for every new resource KDP replaces this workflow with self-service provisioning. A developer opens the service catalog, selects PostgreSQL, and gets a running database. No tickets. No waiting. No Kubernetes expertise required. ## How KDP works KDP has three layers: a control plane built on kcp, a sync mechanism that connects to service clusters, and a dashboard for developers to interact with. ### The foundation: kcp workspaces KDP is built on [kcp](https://www.kubermatic.com/kcp/), a CNCF Sandbox project that Kubermatic actively contributes to. kcp introduces a concept called **workspaces**: lightweight logical Kubernetes clusters that each operate as independent API servers. Think of it this way. Instead of giving every team their own cluster (expensive, hard to manage) or sharing a single cluster with namespace-level RBAC (fragile, noisy-neighbor risks), kcp gives each team a workspace. Each workspace has its own API server, its own resources, and complete isolation from other workspaces, but they all run on shared infrastructure. Workspaces are organized hierarchically. A root workspace sits at the top with nested child workspaces underneath. Platform owners control the top of the tree. Teams manage their own branches. ### The bridge: api-syncagent The api-syncagent connects the KDP control plane to the clusters where services actually run. It's a lightweight connector deployed on each **service cluster**, the cluster managed by a service provider where workloads like databases, message queues, or compute resources actually live. Here's how it works: 1. A service provider operates a cluster with their services (e.g., PostgreSQL via an operator, or cloud resources via Crossplane) 2. They deploy the api-syncagent on that cluster with credentials from KDP 3. They create `PublishedResource` objects that define which resources from their cluster should appear in the KDP catalog 4. The agent syncs those definitions to the KDP control plane 5. Developers see the published services in the catalog and can provision them directly 6. When a developer provisions a service, the api-syncagent synchronizes the request to the local service cluster, where the service provider processes it The developer never touches the service cluster directly. ### The interface: KDP Dashboard ![kdp-dashboard](/static/kdp-dashboard.png) The dashboard is a web UI that talks directly to the Kubernetes API. Everything you can do in the dashboard, you can also do with `kubectl`. There's no proprietary CLI or SDK. From the dashboard, developers can: - Browse the service catalog and see available services - Provision a service instance with a form or via the AI Agent - View status, connection details, and health of their resources - Manage their workspace, invite team members, and organize resources Service providers use the dashboard to register services, generate sync agent credentials, and monitor service health across their clusters. ## Who KDP is for KDP is designed for three roles: ### Platform owners Platform owners run the KDP installation itself. They manage the kcp deployment, configure authentication (KDP uses Dex for OIDC), assign top-level permissions, and ensure platform availability. They set the rules for the workspace hierarchy and decide which service providers can publish to the catalog. ### Service providers Service providers are the teams that operate actual infrastructure: databases, message queues, compute services, AI models. They manage their own service clusters, deploy the api-syncagent, and decide what to publish to the platform. This is a key design choice: **service providers are not bottlenecked by the central platform team.** They manage their own clusters, their own operators, and their own publishing decisions. The platform team provides the marketplace. Service providers stock the shelves. A service provider can use any technology behind the api-syncagent. Kubernetes operators, Crossplane for cloud resources, or custom controllers all work. The consumer never knows or cares what's underneath. ### Platform users (developers) Developers consume services from the catalog. They own workspaces, organize their teams, and provision resources through the dashboard or `kubectl`. They never need to interact with the underlying service cluster. When a developer creates a PostgreSQL instance from the catalog, they see status updates and connection details in their workspace. The fact that the database is running on a completely separate cluster, managed by a different team, is invisible to them. ## Crossplane integration KDP includes built-in support for [Crossplane](https://www.crossplane.io) to expose cloud resources as platform services. A service provider can publish managed cloud services (an AWS RDS instance, a Google Cloud SQL database, an Azure Storage account) through the same catalog interface that handles in-cluster services. The pattern: 1. Service provider installs a Crossplane provider (AWS, GCP, Azure) on their service cluster 2. They define Crossplane Compositions that abstract complex cloud resources into simple interfaces 3. They create `PublishedResource` objects to expose these compositions through KDP 4. Developers provision cloud resources from the catalog like any other service This also enables cloud service filtering. The service provider explicitly defines which resources to publish, so developers only see approved services in the catalog. If your organization only permits certain cloud services, the provider publishes only those. Everything else is invisible, not just restricted. ## AI capabilities KDP uses AI in two ways: generating resources for developers and designing service forms for providers. The workspace model also doubles as a governance layer for AI infrastructure. Organizations control which teams access which AI models or compute resources by choosing what to publish and to whom. ### AI Agent: natural language to Kubernetes KDP includes an optional AI Agent, deployed as a separate component during installation, that is built into the dashboard. Developers describe what they need in natural language ("a PostgreSQL database with 50GB storage for my analytics team") and the agent generates the corresponding Kubernetes resource YAML. The generated manifest appears in the dashboard for the developer to review and edit before submitting. The AI Agent requires an OpenAI API key. ### AI UI Builder: prompt-designed service forms ![ai-builder](/static/kdp-ui-builder.png) Service providers publish resources to the catalog, but the default provisioning forms are generic. Most service providers aren't UI experts, and they shouldn't need to be. KDP's AI UI Builder lets service providers describe the interface they want in natural language and generates a custom form for their service. A provider can prompt iteratively ("create a form with dropdowns for instance size", "highlight required fields in red", "add a tooltip explaining backup retention") and the generated UI replaces the default form in the dashboard. Forms can also be configured via annotations in the service definition on the service cluster, giving providers a code-first alternative. ## How KDP compares ### vs. Backstage Backstage is a developer portal framework. It provides a catalog and plugin system for building a custom developer UI. KDP is a developer platform. It provides the provisioning engine, multi-tenancy, and service lifecycle management underneath. They can work together: Backstage as the portal, KDP as the platform backend. ### vs. Port / Cortex Port and Cortex are commercial developer portals focused on the interface and catalog layer. They're strong at discovery, scorecards, and developer experience. KDP focuses on the infrastructure layer: provisioning, workspace isolation, and service lifecycle. If you need a polished portal UI with deep integrations, Port or Cortex serve that role. If you need the engine that actually provisions and isolates resources, that's KDP. ### vs. Humanitec Humanitec operates as a Platform Orchestrator with its Score specification for environment configuration. KDP takes a different approach, using standard Kubernetes APIs rather than a new specification. Both solve the backend orchestration problem, but KDP is more deeply tied to the Kubernetes ecosystem. ### At a glance | Feature | KDP | Backstage | Humanitec | | --- | --- | --- | --- | | **Primary Focus** | Infrastructure Orchestration | Developer UI & Portal | Platform Orchestration | | **Philosophy** | Native Kubernetes APIs | Plugin-based Framework | Score (Workload Spec) | | **Multi-tenancy** | Workspace-level (kcp) | UI-level RBAC | Environment-level | | **Cloud Integration** | Crossplane (Native) | Plugins / Manual | Driver-based | ### vs. DIY (Terraform + ArgoCD + Backstage + ...) Building an IDP from scratch means stitching together multiple tools and maintaining the integrations yourself. KDP provides an integrated stack so platform teams spend their time building golden paths instead of maintaining the platform. ## Getting started KDP requires a Kubernetes cluster (minimum 3 nodes) with a CSI driver, cert-manager, and an Ingress controller (NGINX or Gateway API). Installation follows a Helm-based workflow: cert-manager, then Dex for authentication, then kcp, then KDP controllers, then the dashboard, and optionally the AI Agent. KDP is an enterprise product. You'll need Docker registry credentials from Kubermatic to access the Helm charts. Contact [Kubermatic](https://kubermatic.com/products/kubermatic-developer-platform) for access and pricing. ## Key takeaways - KDP is a **developer platform**, not a portal. It provisions resources, not just catalogs them. - Built on **kcp** (CNCF Sandbox) with workspace-level multi-tenancy on shared infrastructure. - **Kubernetes APIs all the way down.** If you know `kubectl`, you know KDP. --- ## Deploying KubeOne Clusters on Hetzner Cloud - **URL:** https://www.kubermatic.com/learn/kubeone/kubeone-hetzner-cloud/ - **Date:** 2026-04-30 [Learn](/learn/) / [Kubeone](/learn/kubeone/) / Deploying KubeOne Clusters on Hetzner Cloud kubeone # Deploying KubeOne Clusters on Hetzner Cloud ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Mar 18, 2026 11 min read Intermediate [getting-started](/learn/?tag=getting-started) [automation](/learn/?tag=automation) [multi-cloud](/learn/?tag=multi-cloud) #### Prerequisites - Hetzner Cloud account with an API token ([console.hetzner.cloud](https://console.hetzner.cloud)) - KubeOne installed — see [Installing KubeOne](/learn/kubeone/installing-kubeone-first-cluster/) - Terraform 1.5+ installed - SSH key pair available at `~/.ssh/id_rsa` and `~/.ssh/id_rsa.pub` - kubectl installed on your local machine ## Introduction Hetzner Cloud is a popular choice for Kubernetes deployments in Europe. The pricing is straightforward — shared vCPU servers start at a few euros per month — and the infrastructure is reliable. For teams that do not need the complexity (or cost) of AWS, GCP, or Azure, Hetzner offers everything you need to run production Kubernetes clusters at a fraction of the price. KubeOne has first-class support for Hetzner Cloud. The official Terraform examples handle all the infrastructure provisioning — servers, networks, load balancers, firewalls, and SSH keys — so you do not need to configure any of that manually. You provide a cluster name and an API token, and KubeOne takes care of the rest. In this tutorial, you will deploy a highly available, 3-node Kubernetes cluster on Hetzner Cloud using KubeOne and Terraform. By the end, you will have a production-grade cluster with an external load balancer, private networking, automatic worker node provisioning via machine-controller, and a clear upgrade path for future Kubernetes versions. **What you will learn:** - How to configure the Hetzner Cloud provider for KubeOne - How to use the official Terraform examples to provision infrastructure - How to create and apply a KubeOneCluster manifest for Hetzner - How to verify your cluster and add worker nodes - How to estimate and optimize costs ## Step 1: Generate a Hetzner Cloud API Token KubeOne and Terraform both need an API token to interact with Hetzner Cloud. Log into the [Hetzner Cloud Console](https://console.hetzner.cloud), select your project, and navigate to **Security &gt; API Tokens**. Generate a new token with **Read & Write** permissions. Copy the token immediately — Hetzner only shows it once. Export the token as an environment variable. Both Terraform and KubeOne read this variable automatically: ```bash export HCLOUD_TOKEN="your-api-token-here" ``` > **Tip:** For production setups, store the token in a secrets manager or a `.env` file that is excluded from version control. Do not commit API tokens to your repository. Verify the token works by listing your existing servers (the list will be empty if this is a new project): ```bash curl -s -H "Authorization: Bearer $HCLOUD_TOKEN" https://api.hetzner.cloud/v1/servers | jq '.servers | length' ``` **Expected output:** ```text 0 ``` ## Step 2: Set Up the Terraform Configuration KubeOne ships with official, production-tested Terraform examples for every supported cloud provider. Instead of writing Terraform from scratch, you will use the Hetzner example as your starting point. Download the KubeOne release and extract the Terraform examples: ```bash # Download the latest KubeOne release curl -sfL https://get.kubeone.io | sh # The examples are bundled with the release # Copy the Hetzner example to your project directory mkdir kubeone-hetzner && cd kubeone-hetzner cp -r /usr/local/share/kubeone/examples/terraform/hetzner/* . ``` If the examples are not at that path, clone them from GitHub: ```bash mkdir kubeone-hetzner && cd kubeone-hetzner git clone --depth 1 https://github.com/kubermatic/kubeone.git /tmp/kubeone-repo cp -r /tmp/kubeone-repo/examples/terraform/hetzner/* . rm -rf /tmp/kubeone-repo ``` Your directory should now contain: ```text kubeone-hetzner/ ├── main.tf ├── output.tf ├── variables.tf └── versions.tf ``` These files define the complete infrastructure: control plane servers, private network, subnet, load balancer, firewall rules, SSH key, and placement groups for server distribution. ## Step 3: Configure Terraform Variables Create a `terraform.tfvars` file with your cluster settings: ```hcl cluster_name = "production" # Server types — see https://www.hetzner.com/cloud for current pricing control_plane_type = "cpx21" # 3 vCPU, 4 GB RAM, 80 GB SSD worker_type = "cpx31" # 4 vCPU, 8 GB RAM, 160 GB SSD # Datacenter location datacenter = "nbg1" # Nuremberg. Alternatives: fsn1 (Falkenstein), hel1 (Helsinki) # Worker nodes managed by machine-controller initial_machinedeployment_replicas = 2 # SSH key for node access ssh_public_key_file = "~/.ssh/id_rsa.pub" ``` ### Choosing Server Types Hetzner Cloud offers shared vCPU (CX/CPX series) and dedicated vCPU (CCX series) servers. For Kubernetes: | Role | Recommended Type | Specs | Approx. Monthly Cost | |---------------------|------------------|---------------------------|----------------------| | Control plane | cpx21 | 3 vCPU, 4 GB RAM, 80 GB | ~5 EUR | | Workers (general) | cpx31 | 4 vCPU, 8 GB RAM, 160 GB | ~10 EUR | | Workers (compute) | cpx41 | 8 vCPU, 16 GB RAM, 240 GB | ~19 EUR | | Workers (dedicated) | ccx13 | 2 vCPU, 8 GB RAM, 80 GB | ~14 EUR | | Load balancer | lb11 | 25 targets, 5 services | ~6 EUR | > **Note:** Hetzner regularly updates their server types and pricing. Check the [Hetzner Cloud pricing page](https://www.hetzner.com/cloud/) for current prices before provisioning. ### Available Terraform Variables The Hetzner Terraform example supports these variables: | Variable | Default | Description | |--------------------------------------|---------------------|---------------------------------------| | `cluster_name` | (required) | Name for all resources | | `control_plane_vm_count` | `3` | Number of control plane nodes | | `control_plane_type` | `cx23` | Hetzner server type for control plane | | `worker_type` | `cx23` | Hetzner server type for workers | | `lb_type` | `lb11` | Hetzner load balancer type | | `datacenter` | `nbg1` | Hetzner datacenter | | `os` | `ubuntu` | Operating system (ubuntu or flatcar) | | `ssh_public_key_file` | `~/.ssh/id_rsa.pub` | Path to SSH public key | | `ssh_port` | `22` | SSH port | | `initial_machinedeployment_replicas` | `2` | Number of worker nodes | | `disable_kubeapi_loadbalancer` | `false` | Set true to skip LB creation | ## Step 4: Provision the Infrastructure Initialize Terraform, review the plan, and apply: ```bash terraform init terraform plan ``` Review the plan output. You should see resources being created for: - 3 control plane servers (`hcloud_server.control_plane`) - 1 private network with a subnet (`hcloud_network.net`, `hcloud_network_subnet.kubeone`) - 1 load balancer for the API server (`hcloud_load_balancer.load_balancer`) - 1 firewall with Kubernetes-required ports (`hcloud_firewall.cluster`) - 1 SSH key (`hcloud_ssh_key.kubeone`) - 1 placement group to distribute servers across hosts If everything looks correct, apply: ```bash terraform apply ``` Type `yes` when prompted. Terraform creates all resources in about 1-2 minutes. Export the infrastructure details for KubeOne: ```bash terraform output -json > tf.json ``` Verify the output contains your infrastructure: ```bash cat tf.json | jq '.kubeone_api.value.endpoint' ``` **Expected output:** ```json { "host": "203.0.113.100", "port": 6443 } ``` The host is the public IP of the Hetzner load balancer that fronts your API servers. ## Step 5: Create the KubeOneCluster Manifest Create `kubeone.yaml` with the Hetzner-specific configuration: ```yaml apiVersion: kubeone.k8c.io/v1beta2 kind: KubeOneCluster name: production versions: kubernetes: "v1.30.2" cloudProvider: hetzner: {} external: true containerRuntime: containerd: {} clusterNetwork: cni: canal: {} features: nodeLocalDNS: deploy: true ``` The important Hetzner-specific settings: **`cloudProvider.hetzner: {}`** tells KubeOne to configure Hetzner Cloud integrations. This includes the Hetzner Cloud Controller Manager (CCM), which handles node lifecycle events and provides metadata to Kubernetes about the underlying infrastructure. **`cloudProvider.external: true`** deploys the cloud controller manager as an external component (out-of-tree). This is the recommended approach for all cloud providers in modern Kubernetes. The external CCM runs as a Deployment in the cluster rather than being built into the kubelet. **`clusterNetwork.cni.canal: {}`** deploys Canal (Calico + Flannel) as the CNI plugin. This is KubeOne’s default and works well on Hetzner. Canal provides VXLAN overlay networking for pod-to-pod communication and Calico for network policy enforcement. **`features.nodeLocalDNS`** deploys a DNS cache on every node to reduce latency and CoreDNS load. > **Tip:** You can also use Cilium as your CNI instead of Canal. Replace the `cni` section with `cilium: {}`. Cilium provides advanced networking features like eBPF-based load balancing and network observability, but requires Linux kernel 5.10+ on your nodes (which Hetzner’s Ubuntu images provide). ## Step 6: Provision the Kubernetes Cluster With your infrastructure running and the manifest ready, provision Kubernetes: ```bash kubeone apply --manifest kubeone.yaml --tfjson tf.json ``` KubeOne shows you a summary of what it will do. Review the planned actions — it should list: - 3 control plane hosts with their Hetzner IPs - Kubernetes version v1.30.2 - Canal CNI - Hetzner external cloud provider Confirm to proceed. KubeOne then: 1. Connects to each control plane node over SSH 2. Installs containerd and Kubernetes packages 3. Bootstraps the first control plane node with kubeadm 4. Joins the second and third nodes to form an HA cluster 5. Configures etcd across all three nodes 6. Deploys the Hetzner Cloud Controller Manager 7. Deploys Canal CNI, metrics-server, and node-local DNS 8. Deploys machine-controller for worker node management 9. Creates MachineDeployments for worker nodes (based on `initial_machinedeployment_replicas`) The process takes 5-8 minutes. Do not interrupt it. **Expected output (final lines):** ```text INFO[00:05:32] Downloading kubeconfig... INFO[00:05:32] Ensure MachineDeployments... INFO[00:05:33] Done! ``` ## Step 7: Access and Verify the Cluster KubeOne creates a kubeconfig file in your current directory: ```bash export KUBECONFIG=$(pwd)/production-kubeconfig ``` Check that all control plane nodes are ready: ```bash kubectl get nodes ``` **Expected output:** ```text NAME STATUS ROLES AGE VERSION production-cp-1 Ready control-plane 6m v1.30.2 production-cp-2 Ready control-plane 5m v1.30.2 production-cp-3 Ready control-plane 5m v1.30.2 ``` Worker nodes are provisioned asynchronously by machine-controller. They appear within 2-3 minutes: ```bash kubectl get nodes --watch ``` Once workers appear: ```text NAME STATUS ROLES AGE VERSION production-cp-1 Ready control-plane 8m v1.30.2 production-cp-2 Ready control-plane 7m v1.30.2 production-cp-3 Ready control-plane 7m v1.30.2 production-worker-1 Ready <none> 2m v1.30.2 production-worker-2 Ready <none> 2m v1.30.2 ``` Verify all system pods are running: ```bash kubectl get pods -A ``` You should see pods for the API server, controller manager, scheduler, etcd, CoreDNS, Canal, node-local DNS, machine-controller, and the Hetzner cloud controller manager — all in `Running` state. ### Verify the Hetzner Cloud Controller Manager The CCM handles node metadata and lifecycle events. Verify it is running: ```bash kubectl get pods -n kube-system -l app=hcloud-cloud-controller-manager ``` **Expected output:** ```text NAME READY STATUS RESTARTS AGE hcloud-cloud-controller-manager-xxxxxxxxxx-xxxxx 1/1 Running 0 6m ``` Check that nodes have Hetzner-specific labels: ```bash kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.labels.node\.kubernetes\.io/instance-type}{"\n"}{end}' ``` This should show the Hetzner server type (e.g., `cpx21`) for each node, confirming the CCM is correctly reporting node metadata. ## Step 8: Deploy a Test Workload Verify the cluster is fully functional by deploying nginx: ```bash kubectl create deployment nginx --image=nginx:latest --replicas=4 kubectl get pods -o wide ``` The pods should be distributed across your worker nodes. Verify pod-to-pod networking: ```bash kubectl exec -it $(kubectl get pods -l app=nginx -o jsonpath='{.items[0].metadata.name}') -- curl -s -o /dev/null -w "%{http_code}" http://$(kubectl get pods -l app=nginx -o jsonpath='{.items[1].status.podIP}') ``` A `200` response confirms that overlay networking is working correctly across nodes. Clean up the test deployment: ```bash kubectl delete deployment nginx ``` ## Step 9: Scale Worker Nodes One of the advantages of KubeOne on Hetzner is that worker node scaling is fully automated through machine-controller. You do not need to manually provision servers. ### Scale Existing Workers To increase the worker count, edit the MachineDeployment: ```bash kubectl -n kube-system get machinedeployments kubectl -n kube-system scale machinedeployment production-worker --replicas=4 ``` Machine-controller automatically provisions new Hetzner servers, installs Kubernetes, and joins them to the cluster. New nodes appear within 2-3 minutes. ### Add a Different Worker Pool To add workers with different server types (for example, compute-intensive workloads), create a new MachineDeployment. First, inspect the existing one to use as a template: ```bash kubectl -n kube-system get machinedeployment production-worker -o yaml > worker-pool.yaml ``` Edit `worker-pool.yaml`: change the name, adjust the server type in `cloudProviderSpec`, and update the replica count. Apply the new MachineDeployment: ```bash kubectl apply -f worker-pool.yaml ``` ## Step 10: Understand the Cost Breakdown With the default configuration (3x cpx21 control plane, 2x cpx31 workers, 1x lb11 load balancer), your estimated monthly cost is: | Resource | Type | Count | Approx. Unit Cost | Total | |-----------------|-------|-------|-------------------|-------------------| | Control plane | cpx21 | 3 | ~5 EUR | ~15 EUR | | Workers | cpx31 | 2 | ~10 EUR | ~20 EUR | | Load balancer | lb11 | 1 | ~6 EUR | ~6 EUR | | Private network | — | 1 | Free | 0 EUR | | **Total** | | | | **~41 EUR/month** | > **Note:** Prices are approximate and vary by datacenter. Check [Hetzner Cloud pricing](https://www.hetzner.com/cloud/) for current rates. Traffic within the private network is free. Outbound public traffic is included up to 20 TB/month on most server types. ### Cost Optimization Tips - **Use CX series instead of CPX** for control plane nodes if you do not need AMD EPYC processors. CX series (Intel) is slightly cheaper. - **Start with 2 workers and scale up** as needed. Machine-controller makes scaling a single command. - **Use Hetzner volumes** for persistent storage instead of provisioning larger server types for disk space. - **Set up autoscaling** with the Kubernetes Cluster Autoscaler and Hetzner Cloud provider to scale workers based on demand. ## Troubleshooting ### Terraform Fails with “Unauthorized” The API token is missing or invalid. Verify it is set: ```bash echo $HCLOUD_TOKEN ``` If the variable is empty, re-export it. If it is set but Terraform still fails, generate a new token in the Hetzner Cloud Console — the old one may have been revoked. ### Worker Nodes Not Appearing If control plane nodes are ready but workers do not appear after 5 minutes: 1. Check MachineDeployment status: ```bash kubectl -n kube-system get machinedeployments kubectl -n kube-system get machines ``` 2. Check machine-controller logs: ```bash kubectl -n kube-system logs -l app=machine-controller -f ``` Common causes: the `HCLOUD_TOKEN` secret is missing from the cluster, the token does not have write permissions, or the Hetzner API rate limit has been hit. 3. Verify the cloud-init secret exists: ```bash kubectl -n kube-system get secrets | grep cloud-init ``` ### Nodes Stuck in NotReady If nodes appear but stay in `NotReady` state: 1. Check kubelet logs on the affected node: ```bash ssh root@<node-ip> journalctl -u kubelet -f ``` 2. Check that Canal pods are running on all nodes: ```bash kubectl get pods -n kube-system -l k8s-app=canal -o wide ``` If Canal pods are in `CrashLoopBackOff`, the private network may not be configured correctly. Verify the Hetzner private network exists and all servers are attached to it in the Hetzner Cloud Console. ### API Server Unreachable If kubectl cannot connect after provisioning: 1. Verify the load balancer is healthy in the Hetzner Cloud Console. All three control plane targets should show “healthy.” 2. Check that port 6443 is not blocked by a local firewall or corporate network. 3. Verify the kubeconfig points to the correct load balancer IP: ```bash grep server production-kubeconfig ``` ## Next Steps Your Hetzner Cloud cluster is running and ready for workloads. Here are some paths forward: - [What is KubeOne?](/learn/kubeone/what-is-kubeone/) — if you skipped the concepts overview, read it now for deeper understanding of KubeOne’s architecture - [Bare Metal Kubernetes with KubeOne and Terraform](/learn/kubeone/bare-metal-kubernetes-terraform/) — compare the Hetzner workflow with bare metal provisioning to understand the differences - [KubeOne vs kOps](/learn/kubeone/kubeone-vs-kops/) — understand how KubeOne compares with other cluster management tools - [Migrating from Ingress-Nginx to Gateway API with KubeLB](/learn/kubelb/ingress-nginx-to-gateway-api/) — add Gateway API-based load balancing to your cluster ## Summary You deployed a highly available Kubernetes cluster on Hetzner Cloud using KubeOne and Terraform. The cluster runs three control plane nodes with distributed etcd, two worker nodes managed by machine-controller, and a Hetzner load balancer fronting the API server. The Hetzner Cloud Controller Manager provides node lifecycle management and infrastructure metadata to Kubernetes. The entire setup costs approximately 41 EUR per month and can be upgraded, scaled, or repaired with a single `kubeone apply` command. #### Resources - [KubeOne Documentation](https://docs.kubermatic.com/kubeone/) - [KubeOne Hetzner Terraform Examples](https://github.com/kubermatic/kubeone/tree/main/examples/terraform/hetzner) #### On This Page - [Introduction](#introduction) - [Step 1: Generate a Hetzner Cloud API Token](#step-1-generate-a-hetzner-cloud-api-token) - [Step 2: Set Up the Terraform Configuration](#step-2-set-up-the-terraform-configuration) - [Step 3: Configure Terraform Variables](#step-3-configure-terraform-variables) - [Choosing Server Types](#choosing-server-types) - [Available Terraform Variables](#available-terraform-variables) - [Step 4: Provision the Infrastructure](#step-4-provision-the-infrastructure) - [Step 5: Create the KubeOneCluster Manifest](#step-5-create-the-kubeonecluster-manifest) - [Step 6: Provision the Kubernetes Cluster](#step-6-provision-the-kubernetes-cluster) - [Step 7: Access and Verify the Cluster](#step-7-access-and-verify-the-cluster) - [Verify the Hetzner Cloud Controller Manager](#verify-the-hetzner-cloud-controller-manager) - [Step 8: Deploy a Test Workload](#step-8-deploy-a-test-workload) - [Step 9: Scale Worker Nodes](#step-9-scale-worker-nodes) - [Scale Existing Workers](#scale-existing-workers) - [Add a Different Worker Pool](#add-a-different-worker-pool) - [Step 10: Understand the Cost Breakdown](#step-10-understand-the-cost-breakdown) - [Cost Optimization Tips](#cost-optimization-tips) - [Troubleshooting](#troubleshooting) - [Terraform Fails with “Unauthorized”](#terraform-fails-with-unauthorized) - [Worker Nodes Not Appearing](#worker-nodes-not-appearing) - [Nodes Stuck in NotReady](#nodes-stuck-in-notready) - [API Server Unreachable](#api-server-unreachable) - [Next Steps](#next-steps) - [Summary](#summary) --- ## Bare Metal Kubernetes with KubeOne and Terraform - **URL:** https://www.kubermatic.com/learn/kubeone/bare-metal-kubernetes-terraform/ - **Date:** 2026-04-30 [Learn](/learn/) / [Kubeone](/learn/kubeone/) / Bare Metal Kubernetes with KubeOne and Terraform kubeone # Bare Metal Kubernetes with KubeOne and Terraform ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Mar 17, 2026 19 min read Intermediate [bare-metal](/learn/?tag=bare-metal) [production](/learn/?tag=production) [automation](/learn/?tag=automation) #### Prerequisites - 3 servers (bare metal or VMs) with Ubuntu 22.04+, minimum 2 vCPU and 4 GB RAM each - SSH key-based access to all servers - Terraform 1.5+ installed - KubeOne installed — see [Installing KubeOne](/learn/kubeone/installing-kubeone-first-cluster/) - Basic understanding of Terraform Running Kubernetes on bare metal gives you something that no cloud provider can: full control over your hardware with zero per-hour compute costs. There is no managed service fee, no cloud tax on every CPU cycle, and no surprise bill at the end of the month. You own the servers, and you decide exactly how they are configured. The tradeoff is that bare metal Kubernetes is notoriously manual. Without cloud provider integrations, you are responsible for load balancing, storage provisioning, networking, and every other piece of infrastructure that managed services handle for you. A single misconfigured firewall rule or a missed etcd port can leave you debugging for hours. In this tutorial, you will use KubeOne with Terraform to provision a highly available, 3-node Kubernetes cluster on bare metal servers. KubeOne handles the heavy lifting of bootstrapping kubeadm, configuring etcd for high availability, and deploying the CNI plugin. Terraform provides the structured output format that KubeOne uses to discover your infrastructure. By the end, you will have a production-ready cluster with etcd redundancy across all three control plane nodes and a clear path to adding worker nodes. This is not a toy cluster. The configuration you will build here is suitable for production workloads, with audit logging, node-local DNS caching, and a high availability architecture that tolerates the failure of any single node. ## Step 1: Plan Your Network Architecture Before you install anything or write a single line of configuration, plan your network. Bare metal networking does not forgive mistakes — there is no VPC wizard to set up subnets for you, and a wrong firewall rule can silently break inter-node communication. ### Private Network All three control plane nodes must communicate over a private network. A typical choice is a `10.0.0.0/24` subnet, but any RFC 1918 range works. The critical requirement is that inter-node traffic — etcd replication, kubelet communication, and internal API calls — does not traverse the public internet. If your servers are in the same data center, they likely already share a private network. If they are in different locations, you will need a VPN or overlay network between them. Verify private connectivity before proceeding. SSH into each node and ping the private IPs of the other two. If any of those pings fail, stop here and fix your network. ### Public IPs Each node needs a public IP address for two purposes: SSH access from your workstation and Kubernetes API access. If you are running everything behind a VPN and do not need external API access, you can skip public IPs entirely, but most production setups need at least SSH reachability. ### API Server Load Balancer In a highly available cluster, the Kubernetes API server runs on all three control plane nodes. You need a load balancer in front of them so that kubectl and your applications always reach a healthy API server, even if one node goes down. You have several options: - **External hardware or software load balancer** — HAProxy, Nginx, or an F5 device. This is the most reliable approach. - **DNS round-robin** — Create a DNS A record with all three control plane IPs. This is simple but has no health checks. If one node goes down, roughly one-third of API requests will fail until you update the DNS record. - **keepalived with HAProxy** — Run keepalived on two dedicated hosts (or on two of the control plane nodes) for automatic failover of a virtual IP. This is the gold standard for bare metal HA. For this tutorial, you will set up HAProxy in Step 4. If you already have a load balancer, skip that step and use your existing load balancer’s IP as the API server address. ### Firewall Rules Control plane nodes need specific ports open between them. Get these wrong, and the cluster will fail to form or will exhibit intermittent failures that are difficult to diagnose. | Port | Protocol | Purpose | |-----------|----------|------------------------------------| | 6443 | TCP | Kubernetes API server | | 2379-2380 | TCP | etcd client and peer communication | | 10250 | TCP | kubelet API | | 10259 | TCP | kube-scheduler | | 10257 | TCP | kube-controller-manager | > **Warning:** Port 6443 (API server) must be accessible from wherever you run kubectl. Ports 2379-2380 (etcd) should only be accessible between control plane nodes. Exposing etcd to the internet is a critical security vulnerability — anyone with access to etcd can read and modify every secret, config map, and resource in your cluster. Open these ports between all three control plane nodes on the private network. If you are using `ufw` on Ubuntu: ```bash # Run on each control plane node sudo ufw allow from 10.0.0.0/24 to any port 6443 proto tcp sudo ufw allow from 10.0.0.0/24 to any port 2379:2380 proto tcp sudo ufw allow from 10.0.0.0/24 to any port 10250 proto tcp sudo ufw allow from 10.0.0.0/24 to any port 10259 proto tcp sudo ufw allow from 10.0.0.0/24 to any port 10257 proto tcp ``` Also allow SSH (port 22) from your workstation and port 6443 from wherever you need kubectl access. ## Step 2: Create the Terraform Configuration On cloud providers, Terraform provisions the actual infrastructure — VMs, networks, load balancers. On bare metal, your servers already exist. Terraform’s role here is different: it generates the structured JSON output that KubeOne expects, describing where your servers are and how to reach them. This might feel like overkill for bare metal, but it gives you two significant benefits. First, your infrastructure description is version-controlled and reproducible. Second, if you later move to a cloud provider, your workflow stays the same — only the Terraform configuration changes. Create a project directory: ```bash mkdir kubeone-bare-metal && cd kubeone-bare-metal ``` Create `main.tf` with the following content: ```hcl # For bare metal, Terraform generates the output format that KubeOne expects. # It does not provision infrastructure — your servers already exist. variable "cluster_name" { type = string default = "production" } variable "control_plane_hosts" { type = list(object({ public_address = string private_address = string ssh_user = string })) } variable "api_server_address" { type = string description = "Load balancer or primary control plane IP for API server access" } variable "ssh_private_key_file" { type = string default = "~/.ssh/id_rsa" } output "kubeone_api" { value = { endpoint = { host = var.api_server_address port = 6443 connect_timeout = 60 } } } output "kubeone_hosts" { value = { control_plane = { cluster_name = var.cluster_name hosts = [ for i, host in var.control_plane_hosts : { public_address = host.public_address private_address = host.private_address ssh_user = host.ssh_user ssh_private_key_file = var.ssh_private_key_file ssh_agent_socket = "" } ] } } } ``` The `kubeone_api` output tells KubeOne where the API server is reachable. The `kubeone_hosts` output describes each control plane node — its public and private addresses, the SSH user, and the SSH key to use for authentication. Now create `terraform.tfvars` with your actual server details. Replace the example IPs with your real addresses: ```hcl cluster_name = "production" api_server_address = "203.0.113.10" # Your load balancer IP or primary node IP control_plane_hosts = [ { public_address = "203.0.113.10" private_address = "10.0.0.10" ssh_user = "ubuntu" }, { public_address = "203.0.113.11" private_address = "10.0.0.11" ssh_user = "ubuntu" }, { public_address = "203.0.113.12" private_address = "10.0.0.12" ssh_user = "ubuntu" } ] ``` If you are using a dedicated load balancer, set `api_server_address` to the load balancer’s IP. If you do not have a load balancer yet, use the public IP of the first control plane node for now — you will set up HAProxy in Step 4. ## Step 3: Generate Terraform Output Initialize Terraform, apply the configuration, and export the JSON output that KubeOne needs: ```bash terraform init terraform apply -auto-approve terraform output -json > tf.json ``` Since there are no actual cloud resources to create, `terraform apply` runs instantly. It simply evaluates the variables and generates the outputs. Verify the output looks correct: ```bash cat tf.json ``` You should see a JSON structure containing `kubeone_api` with your API server endpoint and `kubeone_hosts` with the details for all three control plane nodes. If any IP addresses are wrong or the structure looks malformed, fix `terraform.tfvars` and re-run `terraform apply`. The `tf.json` file is what KubeOne reads to discover your infrastructure. Every time you change your server details — replacing a node, changing an IP — update `terraform.tfvars`, re-run the commands above, and regenerate `tf.json`. ## Step 4: Set Up the API Server Load Balancer For a production HA cluster, you need a load balancer in front of the three control plane nodes on port 6443. Without one, your kubeconfig points to a single node, and if that node goes down, you lose API access even though the other two nodes are healthy. ### Option A: HAProxy (Recommended for Bare Metal) HAProxy is the standard choice for bare metal Kubernetes load balancing. It is lightweight, battle-tested, and handles TCP proxying with health checks. Install HAProxy on a separate host. If you do not have a dedicated host available, you can run it on one of the control plane nodes, but a separate host is preferable to avoid a single point of failure. ```bash sudo apt update && sudo apt install haproxy -y ``` Add the following configuration to `/etc/haproxy/haproxy.cfg`. If the file already has content, append this to the end: ```text frontend kubernetes-api bind *:6443 mode tcp default_backend kubernetes-control-plane backend kubernetes-control-plane mode tcp balance roundrobin option tcp-check server cp-1 10.0.0.10:6443 check server cp-2 10.0.0.11:6443 check server cp-3 10.0.0.12:6443 check ``` Replace the `10.0.0.x` addresses with the private IPs of your control plane nodes. The `option tcp-check` directive means HAProxy will verify that each backend server is accepting TCP connections on port 6443 before sending traffic to it. Restart and enable HAProxy: ```bash sudo systemctl restart haproxy sudo systemctl enable haproxy ``` Verify it is running: ```bash sudo systemctl status haproxy ``` If HAProxy is running on a separate host, update `api_server_address` in `terraform.tfvars` to point to the HAProxy host’s IP, then regenerate `tf.json`. ### Option B: DNS Round-Robin (Simpler, Less Reliable) If you want something simpler and can tolerate reduced availability, create a DNS A record that resolves to all three control plane IPs: ```text k8s-api.example.com A 203.0.113.10 k8s-api.example.com A 203.0.113.11 k8s-api.example.com A 203.0.113.12 ``` Set `api_server_address` to `k8s-api.example.com` in your Terraform variables. The downside is significant: DNS round-robin has no health checks. If one node goes down, roughly one-third of connections will fail until you manually remove the dead node’s IP from the DNS record. DNS TTLs mean the stale record can persist for minutes or hours. > **Tip:** For production, use HAProxy with keepalived for automatic failover of the load balancer itself. DNS round-robin is acceptable for development and staging environments but should not be used for workloads that require high availability. ## Step 5: Create the KubeOneCluster Manifest The KubeOneCluster manifest defines the Kubernetes version, cloud provider, CNI plugin, and cluster features. Create `kubeone.yaml`: ```yaml apiVersion: kubeone.k8c.io/v1beta2 kind: KubeOneCluster name: production versions: kubernetes: "v1.30.2" cloudProvider: none: {} containerRuntime: containerd: {} clusterNetwork: cni: canal: {} podSubnet: "10.244.0.0/16" serviceSubnet: "10.96.0.0/12" features: nodeLocalDNS: deploy: true staticAuditLog: enable: true config: policyFilePath: "" logPath: /var/log/kubernetes/audit.log logMaxAge: 30 logMaxBackup: 10 logMaxSize: 100 systemPackages: configureRepositories: true ``` Here is what each section does: **`cloudProvider.none`** tells KubeOne that this is a bare metal deployment. No cloud controller manager will be installed, and no cloud-specific integrations (like automatic load balancer provisioning or persistent disk creation) will be configured. You handle storage and load balancing yourself. **`containerRuntime.containerd`** sets containerd as the container runtime. Docker support was removed from Kubernetes in v1.24, so containerd is the standard choice. KubeOne handles the installation and configuration automatically. **`clusterNetwork.cni.canal`** deploys Canal as the CNI plugin. Canal combines Calico for network policy enforcement with Flannel for overlay networking. This is KubeOne’s default CNI and works well on bare metal because Flannel’s VXLAN overlay handles pod-to-pod networking across nodes without requiring any special network configuration from your infrastructure. **`clusterNetwork.podSubnet`** and **`clusterNetwork.serviceSubnet`** define the IP ranges for pods and services. The defaults shown here are standard Kubernetes defaults. Make sure these ranges do not overlap with your node network (10.0.0.0/24 in our example) or with each other. **`features.nodeLocalDNS`** deploys a DNS cache on every node in the cluster. Without this, every DNS lookup from a pod goes to the CoreDNS pods, which can become a bottleneck in large clusters. With node-local DNS, lookups are served from a local cache first, reducing latency and CoreDNS load. **`features.staticAuditLog`** enables Kubernetes audit logging. Every API request — who made it, what they changed, when it happened — is written to `/var/log/kubernetes/audit.log` on the control plane nodes. This is essential for security compliance and for debugging unexpected changes in your cluster. **`systemPackages.configureRepositories`** allows KubeOne to configure the necessary package repositories (for containerd and Kubernetes) on each node during provisioning. ## Step 6: Provision the Cluster You now have three files in your project directory: `main.tf`, `terraform.tfvars`, and `kubeone.yaml`, along with the generated `tf.json`. Run the provisioning command: ```bash kubeone apply --manifest kubeone.yaml --tfjson tf.json ``` KubeOne will ask you to confirm the planned actions. Review the output — it shows which nodes will be provisioned and what will be installed — then confirm. Here is what happens during provisioning, phase by phase: 1. **Validates connectivity.** KubeOne SSHes into each host, verifies the operating system is supported, checks that the required ports are open, and confirms that the nodes can reach each other on the private network. 2. **Installs container runtime.** Containerd is installed and configured on all three nodes. KubeOne handles the repository setup, package installation, and systemd service configuration. 3. **Installs Kubernetes binaries.** kubeadm, kubelet, and kubectl are installed on all nodes at the version specified in your manifest (v1.30.2 in this case). 4. **Bootstraps the first control plane node.** KubeOne runs `kubeadm init` on the first node with the cluster configuration derived from your manifest and Terraform output. This creates the initial etcd member, generates the cluster certificates, and starts the API server. 5. **Joins remaining control plane nodes.** The second and third nodes join the cluster using `kubeadm join`. Each node gets its own etcd member, API server instance, controller manager, and scheduler. 6. **Configures etcd for high availability.** With three control plane nodes, etcd operates as a three-member cluster. This provides fault tolerance — the cluster remains operational if any single etcd member (and its associated node) goes down. Quorum requires two of three members to be healthy. 7. **Deploys CNI.** Canal is installed across the cluster, enabling pod-to-pod networking and network policy enforcement. 8. **Deploys machine-controller.** The Kubermatic machine-controller is installed in the cluster for declarative worker node management. On bare metal, this uses the static provider. 9. **Generates kubeconfig.** A `production-kubeconfig` file is created in your current directory. This file contains the credentials needed to access your cluster with kubectl. The entire process takes 5 to 10 minutes, depending on your network speed and server performance. Do not interrupt it. > **Warning:** If provisioning fails midway through — a network timeout, a package download failure, an SSH disconnection — run `kubeone apply` again with the same arguments. The command is idempotent. It detects what has already been completed and picks up from where it left off. Do not run `kubeone reset` unless you intentionally want to tear down the entire cluster and start from scratch. ## Step 7: Verify Your Cluster Set the kubeconfig and check your nodes: ```bash export KUBECONFIG=$(pwd)/production-kubeconfig kubectl get nodes ``` You should see three nodes, all in `Ready` state, all with the `control-plane` role: ```text NAME STATUS ROLES AGE VERSION cp-1 Ready control-plane 5m v1.30.2 cp-2 Ready control-plane 4m v1.30.2 cp-3 Ready control-plane 4m v1.30.2 ``` If any node shows `NotReady`, check the kubelet logs on that node: `journalctl -u kubelet -f`. ### Verify etcd Cluster Health The etcd cluster is the backbone of your Kubernetes control plane. Verify all three members are healthy: ```bash kubectl -n kube-system exec -it etcd-cp-1 -- etcdctl \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \ --key=/etc/kubernetes/pki/etcd/healthcheck-client.key \ member list -w table ``` Replace `etcd-cp-1` with the actual name of one of your etcd pods (check with `kubectl get pods -n kube-system | grep etcd`). You should see three members, all with `started` status. ### Verify System Pods Check that all system components are running: ```bash kubectl get pods -A ``` You should see pods for the API server, controller manager, scheduler, etcd, CoreDNS, Canal, node-local DNS, and the machine-controller. All pods should be in `Running` or `Completed` state. Any pod in `CrashLoopBackOff` or `Pending` indicates a problem — check its logs with `kubectl logs -n <namespace> <pod-name>`. ## Step 8: Add Worker Nodes with MachineDeployments Your cluster currently has three control plane nodes, but no dedicated worker nodes. In production, you generally want to separate control plane and worker responsibilities so that application workloads do not compete with etcd and the API server for resources. For bare metal environments, you have two options for adding worker nodes. ### Option A: MachineDeployment with Static Provider If your worker nodes have SSH access from the control plane, you can use the Kubermatic machine-controller’s static provider. Create a file called `workers.yaml`: ```yaml apiVersion: cluster.k8s.io/v1alpha1 kind: MachineDeployment metadata: name: production-workers namespace: kube-system spec: replicas: 3 selector: matchLabels: cluster: production template: metadata: labels: cluster: production spec: providerSpec: value: cloudProvider: "none" cloudProviderSpec: null operatingSystem: "ubuntu" operatingSystemSpec: distUpgradeOnBoot: false versions: kubelet: "v1.30.2" ``` Apply it with: ```bash kubectl apply -f workers.yaml ``` > **Tip:** For bare metal without a cloud API, the machine-controller’s static provider handles node joining if you provide SSH access details. However, for purely bare metal setups where the control plane cannot SSH into worker nodes, manual joining is simpler and more predictable. ### Option B: Manual Worker Node Joining This approach is straightforward and works in any bare metal environment. On the control plane, generate a join command: ```bash kubeadm token create --print-join-command ``` This outputs something like: ```text kubeadm join 203.0.113.10:6443 --token abc123.xyz789 --discovery-token-ca-cert-hash sha256:def456... ``` SSH into each worker node and run the printed command: ```bash kubeadm join 203.0.113.10:6443 --token abc123.xyz789 --discovery-token-ca-cert-hash sha256:def456... ``` Before running this, make sure each worker node has containerd, kubeadm, and kubelet installed at the same version as the control plane. KubeOne does not manage manually joined worker nodes, so you are responsible for keeping the Kubernetes version in sync during upgrades. After joining, verify the worker nodes appear: ```bash kubectl get nodes ``` You should now see your worker nodes alongside the three control plane nodes, all in `Ready` state. ## Step 9: Deploy a Test Workload With worker nodes in the cluster, deploy a simple workload to verify everything is functioning: ```bash kubectl create deployment nginx --image=nginx:latest --replicas=6 kubectl get pods -o wide ``` The six nginx pods should be distributed across your worker nodes. If all pods land on a single node, check that the other nodes are in `Ready` state and do not have any taints preventing scheduling. To verify networking between pods, exec into one pod and curl another: ```bash kubectl exec -it $(kubectl get pods -l app=nginx -o jsonpath='{.items[0].metadata.name}') -- curl -s -o /dev/null -w "%{http_code}" http://$(kubectl get pods -l app=nginx -o jsonpath='{.items[1].status.podIP}') ``` A `200` response confirms that pod-to-pod networking over Canal is working correctly. Clean up the test deployment when you are done: ```bash kubectl delete deployment nginx ``` ## Step 10: Production Hardening Checklist Your cluster is functional, but “functional” and “production-ready” are not the same thing. Before running real workloads, work through this checklist: - **API server load balancer with health checks** — HAProxy with keepalived for automatic failover, not just simple round-robin - **Persistent storage provisioner** — Longhorn for distributed block storage, Rook-Ceph for S3-compatible object storage, or NFS for simpler setups - **Monitoring stack** — Prometheus for metrics collection and alerting, Grafana for dashboards - **Log aggregation** — Loki (lightweight) or the EFK stack (Elasticsearch, Fluentd, Kibana) for centralized logging - **Backup solution** — Velero for cluster state and resource backups, plus separate backup processes for persistent volumes - **Network policies** — Default deny in every namespace, with explicit allow rules for required traffic flows - **Pod security standards** — Enforce the `restricted` or `baseline` Pod Security Standard at the namespace level - **Certificate rotation** — kubeadm handles automatic certificate rotation, but verify it is working by checking certificate expiration dates periodically - **Disaster recovery plan** — Document the etcd snapshot and restore procedure, test it at least once before you need it in an emergency Each of these items deserves its own deep dive, but the cluster you have built provides the foundation for all of them. ## Troubleshooting ### Terraform State Drift If your bare metal infrastructure changes outside of Terraform — a server is replaced, an IP address changes, or you add a new node — update `terraform.tfvars` with the new details and re-run: ```bash terraform apply -auto-approve terraform output -json > tf.json ``` Then run `kubeone apply` again to reconcile the cluster state with the new infrastructure description. ### etcd Quorum Loss During Provisioning If KubeOne fails while joining the second or third control plane node, the etcd cluster may be in a partially formed state. Run `kubeone apply` again — it detects the partial state and attempts to re-converge. KubeOne is designed to handle this scenario gracefully. If repeated `kubeone apply` attempts fail, the etcd state may be unrecoverable without a full reset. In that case, run `kubeone reset --manifest kubeone.yaml --tfjson tf.json` to tear down the cluster entirely, then run `kubeone apply` to start fresh. This destroys all cluster data, so only do it during initial setup. ### SSH Connection Timeouts If KubeOne cannot connect to your servers, verify: 1. Your SSH key is correct and has the right permissions (`chmod 600 ~/.ssh/id_rsa`). 2. The SSH user specified in `terraform.tfvars` exists on each server and has passwordless sudo. 3. Firewall rules allow SSH (port 22) from your workstation to each server. 4. No intermediate NAT or bastion host is interfering with the connection. Test manually with verbose output: ```bash ssh -v -i ~/.ssh/id_rsa ubuntu@203.0.113.10 ``` ### Pods Stuck in ContainerCreating This is almost always a CNI issue. Check that Canal pods are running on every node: ```bash kubectl get pods -n kube-system -l k8s-app=canal ``` If Canal pods are not running, check their logs for errors. The most common cause is that nodes cannot reach each other on the private network. Verify that the private network interfaces are up and that firewall rules allow traffic on the VXLAN port (UDP 8472) between all nodes. ### API Server Unreachable After Setup If kubectl cannot reach the API server after provisioning: 1. **Using a load balancer:** Verify HAProxy is running and forwarding to port 6443 on all three nodes. Check `sudo systemctl status haproxy` and review the HAProxy logs. 2. **Using DNS round-robin:** Verify all three IPs are in the DNS record and that the record has propagated. Run `dig k8s-api.example.com` to check. 3. **Firewall:** Verify that port 6443 is open from your workstation to the load balancer or directly to the control plane nodes. 4. **Kubeconfig:** Verify that the `server` field in your kubeconfig points to the correct address and port. ## Next Steps With your bare metal cluster running, consider these follow-up tutorials: - [Deploying KubeOne Clusters on Hetzner Cloud](/learn/kubeone/kubeone-hetzner-cloud/) — a cloud alternative with lower cost than the major providers, useful for comparison with your bare metal setup - [KubeOne vs kOps](/learn/kubeone/kubeone-vs-kops/) — understand how KubeOne compares with the AWS-focused cluster management tool - [Migrating from Ingress-Nginx to Gateway API with KubeLB](/learn/kubelb/ingress-nginx-to-gateway-api/) — add proper load balancing to your bare metal cluster using Gateway API ## Summary You provisioned a highly available, 3-node Kubernetes cluster on bare metal servers using KubeOne and Terraform. The cluster runs etcd distributed across all three control plane nodes, uses Canal for pod networking and network policy, and has audit logging and node-local DNS enabled out of the box. The key thing to remember about this setup is that `kubeone apply` is your single command for both initial provisioning and ongoing maintenance. When you need to upgrade Kubernetes, change the version in `kubeone.yaml` and run `kubeone apply` again. When a node fails and you replace it, update `terraform.tfvars`, regenerate `tf.json`, and run `kubeone apply`. The same command handles installation, upgrades, and repair. Bare metal Kubernetes requires more upfront effort than a managed service, but the control and cost savings are significant. You now have a cluster that you fully own, with no ongoing compute fees and no vendor lock-in. The production hardening checklist in Step 10 is your roadmap for turning this into a fully production-ready platform. #### Resources - [KubeOne Documentation](https://docs.kubermatic.com/kubeone/) - [KubeOne Terraform Examples](https://github.com/kubermatic/kubeone/tree/main/examples/terraform) - [Canal CNI](https://docs.tigera.io/calico/latest/getting-started/kubernetes/flannel/install-for-flannel) #### On This Page - [Step 1: Plan Your Network Architecture](#step-1-plan-your-network-architecture) - [Private Network](#private-network) - [Public IPs](#public-ips) - [API Server Load Balancer](#api-server-load-balancer) - [Firewall Rules](#firewall-rules) - [Step 2: Create the Terraform Configuration](#step-2-create-the-terraform-configuration) - [Step 3: Generate Terraform Output](#step-3-generate-terraform-output) - [Step 4: Set Up the API Server Load Balancer](#step-4-set-up-the-api-server-load-balancer) - [Option A: HAProxy (Recommended for Bare Metal)](#option-a-haproxy-recommended-for-bare-metal) - [Option B: DNS Round-Robin (Simpler, Less Reliable)](#option-b-dns-round-robin-simpler-less-reliable) - [Step 5: Create the KubeOneCluster Manifest](#step-5-create-the-kubeonecluster-manifest) - [Step 6: Provision the Cluster](#step-6-provision-the-cluster) - [Step 7: Verify Your Cluster](#step-7-verify-your-cluster) - [Verify etcd Cluster Health](#verify-etcd-cluster-health) - [Verify System Pods](#verify-system-pods) - [Step 8: Add Worker Nodes with MachineDeployments](#step-8-add-worker-nodes-with-machinedeployments) - [Option A: MachineDeployment with Static Provider](#option-a-machinedeployment-with-static-provider) - [Option B: Manual Worker Node Joining](#option-b-manual-worker-node-joining) - [Step 9: Deploy a Test Workload](#step-9-deploy-a-test-workload) - [Step 10: Production Hardening Checklist](#step-10-production-hardening-checklist) - [Troubleshooting](#troubleshooting) - [Terraform State Drift](#terraform-state-drift) - [etcd Quorum Loss During Provisioning](#etcd-quorum-loss-during-provisioning) - [SSH Connection Timeouts](#ssh-connection-timeouts) - [Pods Stuck in ContainerCreating](#pods-stuck-in-containercreating) - [API Server Unreachable After Setup](#api-server-unreachable-after-setup) - [Next Steps](#next-steps) - [Summary](#summary) --- ## Getting Started with kcp - **URL:** https://www.kubermatic.com/learn/kcp/kcp-getting-started/ - **Date:** 2026-04-30 [Learn](/learn/) / [Kcp](/learn/kcp/) / Getting Started with kcp kcp # Getting Started with kcp ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Mar 17, 2026 10 min read Beginner [getting-started](/learn/?tag=getting-started) [platform-engineering](/learn/?tag=platform-engineering) [multi-tenancy](/learn/?tag=multi-tenancy) #### Prerequisites - Go 1.21+ installed - kubectl installed - Basic understanding of Kubernetes APIs ## Introduction kcp is a Kubernetes-like control plane that gives you the API machinery of Kubernetes — CRDs, RBAC, admission control, resource management — without pods, nodes, or container orchestration. It is a CNCF Sandbox project designed for building multi-tenant platforms where every team gets an isolated API scope that feels like its own cluster. If you have already read [What is kcp?](/learn/kcp/what-is-kcp/), you understand the concepts. This tutorial puts those concepts into practice. You will install kcp, start a server, create workspaces, define a custom API using a CRD, create resources against that API, and prove that workspaces provide true isolation — all on your local machine, in about twenty minutes. By the end of this walkthrough, you will have a working mental model of how kcp workspaces, custom APIs, and resource isolation fit together. Everything here runs locally. No cloud account, no existing Kubernetes cluster, no special infrastructure required. **What you will learn:** - How to install and start a kcp server - How to create and navigate workspaces - How kcp differs from a regular Kubernetes cluster at the API level - How to define a custom resource (CRD) inside a workspace - How workspace isolation prevents CRDs and resources from leaking across boundaries * * * ## Prerequisites Before you begin, ensure you have: - **Go 1.21 or later** — check with `go version`. [Install Go](https://go.dev/dl/) if needed. - **kubectl** — check with `kubectl version --client`. [Install kubectl](https://kubernetes.io/docs/tasks/tools/) if needed. - **A terminal** — all commands run in a standard shell (bash or zsh). - **Basic Kubernetes knowledge** — you should be comfortable with concepts like CRDs, namespaces, and `kubectl apply`. **Estimated time:** 20 minutes **Environment used in this tutorial:** - OS: macOS or Linux (commands work on both) - kcp: latest release - kubectl: 1.28+ * * * ## Step 1: Install kcp Download the latest pre-built binary from GitHub. This is the fastest way to get started: ```bash # Detect the latest release version KCP_VERSION=$(curl -s https://api.github.com/repos/kcp-dev/kcp/releases/latest | grep tag_name | cut -d '"' -f 4) # Download the binary (adjust the platform suffix for your OS) # Linux: linux_amd64 | macOS Intel: darwin_amd64 | macOS Apple Silicon: darwin_arm64 curl -L -o kcp.tar.gz "https://github.com/kcp-dev/kcp/releases/download/${KCP_VERSION}/kcp_${KCP_VERSION}_linux_amd64.tar.gz" # Extract and install tar xzf kcp.tar.gz sudo mv bin/kcp /usr/local/bin/ sudo mv bin/kubectl-kcp /usr/local/bin/ ``` The archive contains both the `kcp` server binary and the `kubectl-kcp` plugin, which adds workspace management commands to kubectl. Verify both are installed: ```bash kcp --version kubectl kcp --help ``` You should see a version number from the first command and a list of subcommands from the second. > **Tip:** For alternative installation methods — including building from source — see the detailed guide: [Installing kcp and Creating Your First Workspace](/learn/kcp/installing-kcp-first-workspace/). * * * ## Step 2: Start the kcp Server Create a working directory for this tutorial and start the server: ```bash mkdir -p ~/kcp-tutorial && cd ~/kcp-tutorial kcp start ``` kcp boots an embedded etcd instance, sets up the API machinery, and begins listening for connections. You will see log output as it initializes. Once you see lines indicating the server is ready, it is accepting requests. kcp writes an admin kubeconfig file to `.kcp/admin.kubeconfig` in the current directory. You will use this file to connect kubectl. Leave this terminal running. Open a **new terminal** for the remaining steps. In the new terminal, set the KUBECONFIG environment variable: ```bash export KUBECONFIG=~/kcp-tutorial/.kcp/admin.kubeconfig ``` > **Warning:** Every new terminal session needs this `KUBECONFIG` export. If kubectl commands return connection errors, the most likely cause is a missing or incorrect KUBECONFIG path. * * * ## Step 3: Create Your First Workspace When kcp starts, you are in the root workspace — the top of the hierarchy. Verify this: ```bash kubectl kcp workspace . ``` Expected output: ```text Current workspace is "root". ``` Now create a workspace called `team-frontend` and enter it: ```bash kubectl kcp workspace create team-frontend --type universal --enter ``` Expected output: ```text Workspace "team-frontend" (type root:universal) created. Waiting for it to be ready... Workspace "team-frontend" (type root:universal) is ready to use. Current workspace is "root:team-frontend". ``` The `--type universal` flag creates a workspace with the standard set of kcp APIs. The `--enter` flag switches your kubectl context into the new workspace automatically. * * * ## Step 4: Explore the Workspace You are now inside `team-frontend`. This workspace behaves like a Kubernetes API server. Run a familiar command: ```bash kubectl api-resources ``` You will see resources like ConfigMaps, Secrets, ServiceAccounts, Namespaces, and CustomResourceDefinitions. These are the state-management APIs from Kubernetes. What you will **not** see: Pods, Deployments, ReplicaSets, Services, Nodes. Those belong to the compute layer, and kcp does not include them. This is the fundamental difference — you are working with an API server that manages state and schema, not containers. Check the namespaces: ```bash kubectl get namespaces ``` Expected output: ```text NAME STATUS AGE default Active 30s ``` Just like a fresh Kubernetes cluster, you get a `default` namespace. The workspace is a blank slate, ready for your resources and APIs. > **Tip:** From a developer’s perspective, interacting with a kcp workspace is identical to interacting with a Kubernetes cluster. Your existing kubectl commands, YAML manifests, and tooling all work without modification. * * * ## Step 5: Define a Custom API (CRD) One of kcp’s strengths is that each workspace has its own CRD space. You can define custom APIs in one workspace without affecting any other workspace. Create a file called `environment-crd.yaml` that defines a simple `Environment` resource: ```yaml apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: environments.platform.example.com spec: group: platform.example.com names: plural: environments singular: environment kind: Environment shortNames: - env scope: Namespaced versions: - name: v1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: type: object required: - tier - region properties: tier: type: string enum: ["development", "staging", "production"] region: type: string replicas: type: integer minimum: 1 maximum: 10 status: type: object properties: phase: type: string subresources: status: {} ``` Apply the CRD inside the `team-frontend` workspace: ```bash kubectl apply -f environment-crd.yaml ``` Expected output: ```text customresourcedefinition.apiextensions.k8s.io/environments.platform.example.com created ``` Verify the CRD is registered: ```bash kubectl get crds ``` You should see `environments.platform.example.com` listed. The `Environment` API is now available — but only in this workspace. * * * ## Step 6: Create Resources Using the Custom API Now use the custom API to create environment resources. Create a file called `staging-env.yaml`: ```yaml apiVersion: platform.example.com/v1 kind: Environment metadata: name: staging-eu namespace: default spec: tier: staging region: eu-west-1 replicas: 2 ``` Apply it: ```bash kubectl apply -f staging-env.yaml ``` Create a second environment inline: ```bash kubectl apply -f - <<EOF apiVersion: platform.example.com/v1 kind: Environment metadata: name: prod-us namespace: default spec: tier: production region: us-east-1 replicas: 5 EOF ``` List the environments: ```bash kubectl get environments ``` Expected output: ```text NAME AGE staging-eu 15s prod-us 5s ``` Inspect one of them: ```bash kubectl get environment staging-eu -o yaml ``` You will see the full resource with the spec you defined. The CRD validation is enforced — if you try to set `tier` to a value outside the enum, kcp rejects it, just as Kubernetes would. > **Tip:** Use the short name `env` for faster commands: `kubectl get env` works because you defined `shortNames: ["env"]` in the CRD. * * * ## Step 7: Create a Second Workspace and Verify Isolation This is where kcp’s isolation model becomes concrete. Navigate back to the root workspace: ```bash kubectl kcp workspace .. ``` Create a second workspace and enter it: ```bash kubectl kcp workspace create team-backend --type universal --enter ``` Now try to list environments in `team-backend`: ```bash kubectl get environments ``` Expected output: ```text error: the server doesn't have a resource type "environments" ``` The `Environment` CRD does not exist in `team-backend`. It was defined only in `team-frontend`. In regular Kubernetes, CRDs are cluster-scoped — every namespace sees them. In kcp, each workspace is a separate API scope. CRDs defined in one workspace are invisible to every other workspace. Verify there are no CRDs at all in `team-backend`: ```bash kubectl get crds ``` Expected output: ```text No resources found ``` This is true isolation. Team Backend cannot see, use, or interfere with Team Frontend’s custom APIs. Each team has full control over its own API surface. You can define a completely different `Environment` CRD in `team-backend` with different fields, different validation rules, even a different API group — and there will be no conflict with the one in `team-frontend`. ``` flowchart TB Root["root workspace"] subgraph FE["root:team-frontend"] CRD1[CRD: environments.platform.example.com] R1[Environment/staging-eu] R2[Environment/prod-us] CRD1 --> R1 CRD1 --> R2 end subgraph BE["root:team-backend"] Empty["(no CRDs) (no custom resources)"] end Root --> FE Root --> BE FE -. isolated .-x BE ``` > **Warning:** Workspace isolation means APIs are not shared by default. If you want Team Backend to use Team Frontend’s `Environment` API, you need to use kcp’s APIExport and APIBinding mechanism to explicitly share it. That is a separate topic covered in the kcp series. * * * ## Step 8: Clean Up Stop the kcp server by pressing `Ctrl+C` in the terminal where it is running. Remove the working directory and all generated files: ```bash rm -rf ~/kcp-tutorial ``` This removes the embedded etcd data, the generated kubeconfig, and all workspace state. Since everything runs locally, cleanup is straightforward — there is nothing to tear down in the cloud. * * * ## Troubleshooting ### Port 6443 Already in Use **Symptom:** kcp fails to start with an “address already in use” error. **Cause:** Another process — such as minikube, kind, Docker Desktop’s built-in Kubernetes, or a previous kcp instance — is already listening on port 6443. **Solution:** ```bash # Start kcp on a different port kcp start --secure-port=6444 ``` If you change the port, the generated kubeconfig at `.kcp/admin.kubeconfig` will automatically point to the new port. ### KUBECONFIG Not Set **Symptom:** kubectl commands return “The connection to the server localhost:8080 was refused” or similar connection errors. **Cause:** The KUBECONFIG environment variable is not set, or it points to the wrong file. **Solution:** ```bash # Set KUBECONFIG to the kcp admin kubeconfig export KUBECONFIG=~/kcp-tutorial/.kcp/admin.kubeconfig # Verify the connection kubectl cluster-info ``` Remember that this export applies only to the current terminal session. Each new terminal needs the export. ### Workspace Not Found **Symptom:** `kubectl kcp workspace use <name>` returns an error saying the workspace does not exist. **Cause:** You are in the wrong parent workspace. Workspaces are hierarchical — you can only access direct children of your current workspace. **Solution:** ```bash # Navigate to the root workspace first kubectl kcp workspace .. # List available child workspaces kubectl get workspaces # Then switch to the target workspace kubectl kcp workspace use team-frontend ``` ### kubectl kcp: Command Not Found **Symptom:** Running `kubectl kcp` returns “unknown command” or “command not found.” **Cause:** The `kubectl-kcp` plugin binary is not installed or not in your PATH. **Solution:** ```bash # Check if the binary exists which kubectl-kcp # If not found, install it from the kcp release archive sudo mv bin/kubectl-kcp /usr/local/bin/ ``` ### Go Version Mismatch (Building from Source) **Symptom:** `make build` fails with Go version errors. **Cause:** kcp requires Go 1.21 or later. **Solution:** ```bash go version # If below 1.21, upgrade: # macOS: brew upgrade go # Linux: download from https://go.dev/dl/ ``` * * * ## Next Steps Now that you have seen kcp in action, here are the recommended next tutorials: - [**Installing kcp and Creating Your First Workspace**](/learn/kcp/installing-kcp-first-workspace/) — covers installation options in more detail, including building from source, and walks through workspace navigation and CRD isolation step by step. - [**kcp Workspaces vs Namespaces vs vcluster**](/learn/kcp/workspaces-vs-namespaces-vs-vcluster/) — a comparison of the three main multi-tenancy approaches in the Kubernetes ecosystem, so you can evaluate where kcp fits for your use case. - [**What is kcp? Kubernetes Without the Pods**](/learn/kcp/what-is-kcp/) — if you jumped straight to this hands-on guide, the conceptual article explains the architecture, use cases, and design decisions behind kcp. * * * ## Summary In this tutorial, you installed kcp, started a local server, and worked through a complete hands-on workflow. You created two workspaces (`team-frontend` and `team-backend`), defined a custom `Environment` API using a CRD in one workspace, created resources against that API, and verified that the CRD and its resources are completely invisible from the other workspace. The key takeaways: - **kcp provides Kubernetes API machinery without the compute layer.** You get CRDs, RBAC, namespaces, and resource management, but no pods, nodes, or scheduler. - **Workspaces are true isolation boundaries.** Each workspace has its own CRD space, its own resources, and its own API surface. Unlike Kubernetes namespaces, workspaces isolate cluster-scoped resources like CRDs. - **The developer experience is familiar.** You use kubectl, write standard YAML, and interact with standard Kubernetes APIs. The only difference is what those APIs manage. This isolation model is what makes kcp a strong foundation for multi-tenant platforms. Each team or tenant gets a workspace that looks and feels like a dedicated cluster, while you run a single kcp instance behind the scenes. #### Resources - [kcp Documentation](https://docs.kcp.io/) - [kcp GitHub Repository](https://github.com/kcp-dev/kcp) - [kcp GitHub Releases](https://github.com/kcp-dev/kcp/releases) #### On This Page - [Introduction](#introduction) - [Prerequisites](#prerequisites) - [Step 1: Install kcp](#step-1-install-kcp) - [Step 2: Start the kcp Server](#step-2-start-the-kcp-server) - [Step 3: Create Your First Workspace](#step-3-create-your-first-workspace) - [Step 4: Explore the Workspace](#step-4-explore-the-workspace) - [Step 5: Define a Custom API (CRD)](#step-5-define-a-custom-api-crd) - [Step 6: Create Resources Using the Custom API](#step-6-create-resources-using-the-custom-api) - [Step 7: Create a Second Workspace and Verify Isolation](#step-7-create-a-second-workspace-and-verify-isolation) - [Step 8: Clean Up](#step-8-clean-up) - [Troubleshooting](#troubleshooting) - [Port 6443 Already in Use](#port-6443-already-in-use) - [KUBECONFIG Not Set](#kubeconfig-not-set) - [Workspace Not Found](#workspace-not-found) - [kubectl kcp: Command Not Found](#kubectl-kcp-command-not-found) - [Go Version Mismatch (Building from Source)](#go-version-mismatch-building-from-source) - [Next Steps](#next-steps) - [Summary](#summary) --- ## Installing kcp and Creating Your First Workspace - **URL:** https://www.kubermatic.com/learn/kcp/installing-kcp-first-workspace/ - **Date:** 2026-04-30 [Learn](/learn/) / [Kcp](/learn/kcp/) / Installing kcp and Creating Your First Workspace kcp # Installing kcp and Creating Your First Workspace ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Mar 17, 2026 10 min read Beginner [getting-started](/learn/?tag=getting-started) [platform-engineering](/learn/?tag=platform-engineering) #### Prerequisites - Go 1.21 or later installed - kubectl installed and configured - Basic understanding of Kubernetes APIs — see [What is kcp?](/learn/kcp/what-is-kcp/) ## Introduction In the [previous article](/learn/kcp/what-is-kcp/), you learned what kcp is and why it exists: a Kubernetes API server focused on state and API management, without the compute layer. That was theory. Now you are going to get your hands dirty. In this tutorial, you will install kcp on your local machine, start a server, create multiple workspaces, and see workspace isolation in action. By the end, you will understand how kcp workspaces provide independent API scopes — each with its own resources, its own CRDs, and its own view of the world. You will also see why this matters for platform engineering: workspaces give you the isolation of separate clusters without the operational overhead of actually running them. Everything in this tutorial runs locally. You do not need a Kubernetes cluster, a cloud account, or any special infrastructure. Just a terminal and about fifteen minutes. ## Step 1: Install kcp You have two options for installing kcp: download a pre-built binary or build from source. The pre-built binary is faster and works for most people. ### Option A: Download a Pre-Built Binary (Recommended) Grab the latest release from GitHub. The following commands detect the latest version, download it, extract it, and move the binary to your PATH: ```bash KCP_VERSION=$(curl -s https://api.github.com/repos/kcp-dev/kcp/releases/latest | grep tag_name | cut -d '"' -f 4) curl -L -o kcp.tar.gz "https://github.com/kcp-dev/kcp/releases/download/${KCP_VERSION}/kcp_${KCP_VERSION}_linux_amd64.tar.gz" tar xzf kcp.tar.gz sudo mv bin/kcp /usr/local/bin/ ``` If you are on macOS, replace `linux_amd64` with `darwin_amd64` (Intel) or `darwin_arm64` (Apple Silicon). ### Option B: Build from Source If you prefer to build from source, or if you want to work with the latest development version, clone the repository and build: ```bash git clone https://github.com/kcp-dev/kcp.git cd kcp make build sudo mv bin/kcp /usr/local/bin/ ``` Building from source requires Go 1.21 or later. If the build fails with version errors, check your Go version with `go version` and upgrade if needed. ### Verify the Installation Regardless of which option you chose, verify that kcp is installed correctly: ```bash kcp --version ``` You should see the version number printed to the terminal. If you get a “command not found” error, make sure `/usr/local/bin/` is in your PATH. ## Step 2: Install the kubectl kcp Plugin kcp ships with a kubectl plugin that adds workspace management commands. This plugin is essential — it is how you create, navigate, and manage workspaces from the command line. If you downloaded the pre-built binary in Step 1, the plugin is already in the extracted archive: ```bash sudo mv bin/kubectl-kcp /usr/local/bin/ ``` If you built from source, the plugin binary is in the same `bin/` directory as the kcp binary. Verify the plugin is installed: ```bash kubectl kcp --help ``` You should see a list of subcommands including `workspace`. This plugin extends kubectl with kcp-specific operations — workspace creation, navigation, and management — while keeping the standard kubectl experience you already know. ## Step 3: Start the kcp Server Open a terminal and start the kcp server: ```bash kcp start ``` kcp boots up quickly. Behind the scenes, it starts an embedded etcd instance for storage and sets up the Kubernetes API machinery. You will see log output as it initializes. Once you see lines indicating the server is ready and listening, you are good to go. kcp generates an admin kubeconfig file at `.kcp/admin.kubeconfig` in the directory where you ran the command. You will use this file to connect kubectl to your kcp server. Leave this terminal running. Open a new terminal for the remaining steps. > **Tip:** For a clean start, you can pass `--root-directory` to specify where kcp stores its data. This is useful if you want to keep your experiments organized. To reset everything, just delete that directory and start again. ## Step 4: Connect to kcp with kubectl In your new terminal, point kubectl at the kcp server using the generated kubeconfig: ```bash export KUBECONFIG=$(pwd)/.kcp/admin.kubeconfig ``` Make sure you run this from the same directory where you started kcp, since the kubeconfig path is relative. Now, list the available API resources: ```bash kubectl api-resources ``` Look at the output carefully. You will see familiar Kubernetes API resources — ConfigMaps, Secrets, ServiceAccounts, Namespaces, CustomResourceDefinitions, and more. But you will *not* see Pods, Deployments, Services, or Nodes. Those belong to the compute layer, and kcp does not include them. This is the key point from the previous article, now visible in practice: you are talking to a Kubernetes API server that manages state and APIs, not compute. Run one more command to confirm things are working: ```bash kubectl get namespaces ``` You will see the `default` namespace, just like regular Kubernetes. The API behaves exactly as you expect — it just does not have a scheduler or kubelet behind it. ## Step 5: Explore the Root Workspace kcp organizes everything into a hierarchy of workspaces. When you first start the server, you are in the **root workspace** — the top of the hierarchy. Check where you are: ```bash kubectl kcp workspace . ``` This prints your current workspace location. You should see you are at the root. List the available workspace types: ```bash kubectl get workspacetypes ``` Workspace types define what APIs and capabilities are available in a workspace when it is created. The `universal` type includes the standard set of Kubernetes APIs (minus compute resources) and is the one you will use most often for general-purpose workspaces. Think of the root workspace as the top-level organizational unit. In a real deployment, you would create child workspaces here for teams, projects, or environments. That is exactly what you will do next. ## Step 6: Create Your First Workspace Create a workspace called `team-alpha`: ```bash kubectl kcp workspace create team-alpha --type universal --enter ``` The `--type universal` flag tells kcp to create a workspace with the standard set of APIs. The `--enter` flag automatically switches your kubectl context to the new workspace, so you do not have to navigate to it manually. Verify where you are: ```bash kubectl kcp workspace . ``` You should see that you are now inside `team-alpha`. From this point on, every kubectl command you run operates within this workspace. It is as if you switched to an entirely different Kubernetes cluster — except you did not. You are still talking to the same kcp server. ## Step 7: Create Resources in the Workspace Create a ConfigMap inside `team-alpha`: ```bash kubectl create configmap app-config --from-literal=env=staging --from-literal=region=eu-west ``` Verify it exists: ```bash kubectl get configmaps ``` You should see `app-config` listed alongside the default `kube-root-ca.crt` ConfigMap. This resource exists only in `team-alpha`. No other workspace can see it, modify it, or even know it exists. This is true isolation — not just RBAC rules preventing access, but complete separation at the API level. ## Step 8: Create a Second Workspace and Verify Isolation Navigate back to the root workspace: ```bash kubectl kcp workspace .. ``` Create a second workspace: ```bash kubectl kcp workspace create team-beta --type universal --enter ``` Now list ConfigMaps in `team-beta`: ```bash kubectl get configmaps ``` No `app-config` here. The only ConfigMap is the default `kube-root-ca.crt`. The workspace `team-beta` is completely isolated from `team-alpha`. It has its own resources, its own namespace structure, and its own view of the API. Create a ConfigMap with the *same name* in `team-beta`: ```bash kubectl create configmap app-config --from-literal=env=production --from-literal=region=us-east ``` This works without any conflict. Both workspaces now have a ConfigMap called `app-config` in the `default` namespace, but with different content. There is no collision, no naming convention needed, no prefix hack. > **Warning:** Workspaces are not namespaces. Two workspaces can have resources with the same name and namespace without conflicting. This is true isolation at the API server level. In regular Kubernetes, you cannot have two CRDs with the same name, even in different namespaces, because CRDs are cluster-scoped. In kcp, each workspace has its own CRD space. This distinction matters enormously for multi-tenancy. ## Step 9: Navigate Between Workspaces kcp makes switching between workspaces straightforward. Navigate up and down the hierarchy like a filesystem: ```bash kubectl kcp workspace .. # Go up to the parent (root) workspace kubectl kcp workspace use team-alpha # Switch to team-alpha kubectl get configmaps # See team-alpha's ConfigMap (env=staging) ``` ```bash kubectl kcp workspace use team-beta # Switch to team-beta kubectl get configmaps # See team-beta's ConfigMap (env=production) ``` Each time you switch, your kubectl context changes. The resources you see are those belonging to the current workspace and nothing else. The experience is identical to switching between different Kubernetes clusters, except it happens instantly — no new API server to connect to, no kubeconfig juggling. ## Step 10: Apply a CRD in One Workspace This step demonstrates one of the most powerful differences between workspaces and namespaces: CRD isolation. First, create a file called `database-crd.yaml` with the following content: ```yaml apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: databases.example.com spec: group: example.com names: plural: databases singular: database kind: Database scope: Namespaced versions: - name: v1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: engine: type: string size: type: string ``` Switch to `team-alpha` and apply the CRD: ```bash kubectl kcp workspace use team-alpha kubectl apply -f database-crd.yaml ``` Verify the CRD exists in `team-alpha`: ```bash kubectl get crds ``` You should see `databases.example.com` listed. Now switch to `team-beta` and check: ```bash kubectl kcp workspace use team-beta kubectl get crds ``` The CRD does not exist in `team-beta`. In regular Kubernetes, CRDs are cluster-scoped — every namespace in the cluster sees them, and any CRD name collision affects the entire cluster. In kcp, each workspace has its own CRD space. Team Alpha can define a `Database` CRD with one schema, and Team Beta can define its own `Database` CRD with a completely different schema, and they will never interfere with each other. This is the isolation property that makes kcp compelling for platform engineering. You can give each team full control over their API surface — including the ability to define custom resources — without worrying about conflicts with other teams. ``` flowchart TB Root["root"] subgraph A["team-alpha"] CM1["ConfigMap/app-config env=staging"] CRD1["CRD: databases.example.com"] end subgraph B["team-beta"] CM2["ConfigMap/app-config env=production"] NoCRD["(no databases CRD)"] end Root --> A Root --> B A -. same name, different data .- B ``` ## Common Issues **Port 6443 already in use.** Another kcp instance or a Kubernetes process (like minikube or kind) is already running on that port. Either stop the other process or start kcp with a different port: ```bash kcp start --secure-port=6444 ``` **kubectl kcp: command not found.** The kubectl-kcp plugin binary is not in your PATH. Verify it exists in `/usr/local/bin/` or wherever your Go binaries live. You can also check with `ls /usr/local/bin/kubectl-kcp`. If you built from source, it may be in the `bin/` directory of the kcp repository. **Go version mismatch when building from source.** kcp requires Go 1.21 or later. Check your installed version with `go version` and upgrade if needed. On macOS, `brew upgrade go` handles this. On Linux, download the latest version from the [Go downloads page](https://go.dev/dl/). **kubeconfig not found.** Make sure you run the `export KUBECONFIG` command from the same directory where you started kcp. The `.kcp/admin.kubeconfig` file is created relative to the working directory of the `kcp start` command. ## Next Steps You now have a working kcp installation and an understanding of how workspaces provide isolation. Here is where to go next: - [Sharing APIs Across Workspaces with APIExport and APIBinding](/learn/kcp/sharing-apis-apiexport-apibinding/) (coming soon) — the next article in this series. You will learn how to expose APIs from one workspace and consume them in another, which is the foundation of kcp’s service marketplace model. - [kcp Workspaces vs Namespaces vs vcluster](/learn/kcp/workspaces-vs-namespaces-vs-vcluster/) — a deeper comparison of multi-tenancy approaches if you want to understand where kcp fits relative to other tools. ## Summary You installed kcp, started a local server, created two isolated workspaces, and demonstrated that resources — including CRDs — in one workspace are invisible to the other. You navigated between workspaces, verified that identically-named resources can coexist without conflict, and saw that CRD isolation is one of the sharpest differences between kcp workspaces and Kubernetes namespaces. This is the foundation of kcp’s approach to multi-tenancy: full API-level isolation without the overhead of running separate clusters. Each workspace behaves like its own Kubernetes API server, but they all run on a single kcp instance. For platform teams, this means you can offer every tenant their own isolated API space — with their own CRDs, their own RBAC, their own resources — at a fraction of the cost of dedicated clusters. In the next tutorial, you will learn how to break down those isolation boundaries selectively using APIExport and APIBinding, so workspaces can share APIs without losing their independence. #### Resources - [kcp Documentation](https://docs.kcp.io/) - [kcp GitHub Releases](https://github.com/kcp-dev/kcp/releases) - [kcp kubectl Plugin](https://docs.kcp.io/kcp/main/setup/kubectl-plugin/) #### On This Page - [Introduction](#introduction) - [Step 1: Install kcp](#step-1-install-kcp) - [Option A: Download a Pre-Built Binary (Recommended)](#option-a-download-a-pre-built-binary-recommended) - [Option B: Build from Source](#option-b-build-from-source) - [Verify the Installation](#verify-the-installation) - [Step 2: Install the kubectl kcp Plugin](#step-2-install-the-kubectl-kcp-plugin) - [Step 3: Start the kcp Server](#step-3-start-the-kcp-server) - [Step 4: Connect to kcp with kubectl](#step-4-connect-to-kcp-with-kubectl) - [Step 5: Explore the Root Workspace](#step-5-explore-the-root-workspace) - [Step 6: Create Your First Workspace](#step-6-create-your-first-workspace) - [Step 7: Create Resources in the Workspace](#step-7-create-resources-in-the-workspace) - [Step 8: Create a Second Workspace and Verify Isolation](#step-8-create-a-second-workspace-and-verify-isolation) - [Step 9: Navigate Between Workspaces](#step-9-navigate-between-workspaces) - [Step 10: Apply a CRD in One Workspace](#step-10-apply-a-crd-in-one-workspace) - [Common Issues](#common-issues) - [Next Steps](#next-steps) - [Summary](#summary) --- ## Installing KubeOne: Your First Cluster in 15 Minutes - **URL:** https://www.kubermatic.com/learn/kubeone/installing-kubeone-first-cluster/ - **Date:** 2026-04-30 [Learn](/learn/) / [Kubeone](/learn/kubeone/) / Installing KubeOne: Your First Cluster in 15 Minutes kubeone # Installing KubeOne: Your First Cluster in 15 Minutes ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Mar 17, 2026 10 min read Beginner [getting-started](/learn/?tag=getting-started) [automation](/learn/?tag=automation) #### Prerequisites - One server or VM with Ubuntu 22.04+ (minimum 2 vCPU, 4 GB RAM) - SSH key-based access to the server - kubectl installed on your local machine - Basic understanding of KubeOne — see [What is KubeOne?](/learn/kubeone/what-is-kubeone/) ## Introduction In this tutorial, you will install KubeOne and use it to provision a single-node Kubernetes cluster on any server you can SSH into. This is the fastest way to get a working cluster with KubeOne — no cloud provider account required, no Terraform, no load balancer setup. Just a server, an SSH key, and a YAML file. Production setups use three control plane nodes for high availability. Starting with one node gets you familiar with the workflow without the infrastructure overhead. Once you understand how KubeOne works, scaling to a full HA cluster is a matter of adding more hosts to the manifest. By the end of this tutorial, you will have a running Kubernetes cluster, a deployed test workload, and a solid understanding of KubeOne’s apply-based workflow. ## Step 1: Install KubeOne KubeOne ships as a single static binary with no external dependencies. The fastest way to install it is with the official install script: ```bash curl -sfL https://get.kubeone.io | sh ``` This downloads the latest stable release and places the `kubeone` binary in `/usr/local/bin`. Verify the installation: ```bash kubeone version ``` You should see output showing the KubeOne version, the Go version it was compiled with, and your operating system. Any recent version (1.7+) will work for this tutorial. If you prefer to install a specific version, download it directly from the [GitHub releases page](https://github.com/kubermatic/kubeone/releases). Each release includes binaries for Linux (amd64, arm64), macOS, and Windows. > **Tip:** KubeOne is a single static binary with no dependencies. It works on Linux, macOS, and Windows (WSL). You do not need Docker, Helm, or any other tool installed locally — just KubeOne and kubectl. ## Step 2: Prepare Your Server You need one server that meets these requirements: - **Operating system**: Ubuntu 22.04 or later (Debian, CentOS, and other distributions also work, but this tutorial uses Ubuntu) - **Resources**: At least 2 vCPU and 4 GB RAM - **Network**: A public IP address reachable from your local machine - **Access**: SSH key-based authentication configured for a user with sudo privileges This can be a cloud VM from any provider — DigitalOcean, Hetzner, AWS EC2, Google Compute Engine, Azure — or a local VM created with Multipass, Vagrant, or VirtualBox. The only requirement is that you can reach it over SSH. Verify that your SSH connection works: ```bash ssh -i ~/.ssh/your-key ubuntu@YOUR_SERVER_IP "hostname" ``` Replace `~/.ssh/your-key` with the path to your private SSH key, `ubuntu` with the SSH user on your server, and `YOUR_SERVER_IP` with the actual IP address. If this command prints the server’s hostname, you are ready to proceed. > **Warning:** KubeOne requires passwordless SSH key authentication. Password-based SSH will not work. If you are using a cloud provider, most create VMs with SSH key access by default. For local VMs, generate a key pair with `ssh-keygen` and copy the public key to the server with `ssh-copy-id`. Make sure the following ports are open on the server’s firewall or security group: | Port | Protocol | Purpose | |-------------|----------|---------------------------------| | 22 | TCP | SSH access for KubeOne | | 6443 | TCP | Kubernetes API server | | 30000-32767 | TCP | NodePort services (for testing) | If your server is behind a cloud security group, add rules to allow inbound traffic on these ports from your local IP address. ## Step 3: Create the KubeOneCluster Manifest The KubeOneCluster manifest is a YAML file that describes your desired cluster state. KubeOne reads this file and handles everything needed to make the cluster match what you declared. Create a file called `kubeone.yaml` in a new directory on your local machine: ```bash mkdir my-first-cluster && cd my-first-cluster ``` Then create the manifest: ```yaml apiVersion: kubeone.k8c.io/v1beta2 kind: KubeOneCluster name: my-first-cluster versions: kubernetes: "v1.30.2" cloudProvider: none: {} controlPlane: hosts: - publicAddress: "YOUR_SERVER_IP" privateAddress: "YOUR_SERVER_IP" sshUser: "ubuntu" sshPrivateKeyFile: "~/.ssh/your-key" ``` Replace `YOUR_SERVER_IP` with your server’s actual IP address, `ubuntu` with your SSH user, and `~/.ssh/your-key` with the path to your SSH private key. Here is what each field does: - **`versions.kubernetes`** : The exact Kubernetes version to install. KubeOne supports all actively maintained Kubernetes releases. Check the [compatibility matrix](https://docs.kubermatic.com/kubeone/main/architecture/compatibility/supported-versions/) for the full list. - **`cloudProvider.none`** : Tells KubeOne there is no cloud provider integration. This is the right choice when you are working with bare metal servers, local VMs, or any infrastructure where you do not need cloud-specific features like automatic load balancers or persistent volume provisioning. - **`controlPlane.hosts`** : The list of servers that will run the Kubernetes control plane. For this tutorial, there is one host. The `publicAddress` is the IP that KubeOne connects to over SSH. The `privateAddress` is the IP that Kubernetes components use to communicate with each other. On a single server with one network interface, these are the same IP. This manifest is your single source of truth for the cluster. Version control it alongside your other infrastructure files. ## Step 4: Provision the Cluster With the manifest ready, run: ```bash kubeone apply --manifest kubeone.yaml ``` KubeOne will ask you to confirm the operation. Type `yes` to proceed. Here is what happens next: 1. **SSH connection** — KubeOne connects to the server using the credentials in your manifest. 2. **Container runtime** — It installs and configures containerd as the container runtime. 3. **Kubernetes components** — It installs kubeadm, kubelet, and kubectl on the server. 4. **Cluster bootstrap** — It runs `kubeadm init` to initialize the Kubernetes control plane, including etcd, the API server, controller manager, and scheduler. 5. **CNI installation** — It deploys Canal (Calico + Flannel) as the Container Network Interface plugin, which handles pod-to-pod networking. 6. **Machine controller** — It deploys the Kubermatic machine-controller, which manages worker nodes. For this single-node setup you will not use it, but it is available for future expansion. 7. **Kubeconfig generation** — It creates a kubeconfig file for accessing the cluster from your local machine. The entire process takes 3 to 5 minutes, depending on your server’s internet speed and resources. KubeOne prints detailed output as it works through each step, so you can follow along and see exactly what is happening. When the process completes, KubeOne creates a file called `my-first-cluster-kubeconfig` in your current directory. This file contains the credentials and endpoint information needed to connect to your cluster. ## Step 5: Access Your Cluster Set the `KUBECONFIG` environment variable to point to the generated kubeconfig: ```bash export KUBECONFIG=$(pwd)/my-first-cluster-kubeconfig ``` Now verify that you can reach the cluster: ```bash kubectl get nodes ``` You should see output similar to this: ```text NAME STATUS ROLES AGE VERSION your-server Ready control-plane 2m v1.30.2 ``` The `Ready` status means the node is healthy and accepting workloads. The `control-plane` role confirms this is the control plane node. Check that all system components are running: ```bash kubectl get pods -A ``` You should see pods in the `Running` state for these components: - **coredns** — cluster DNS - **canal** (or calico/flannel) — pod networking - **kube-proxy** — service networking - **kube-apiserver** — the Kubernetes API - **kube-controller-manager** — reconciliation loops - **kube-scheduler** — pod scheduling - **etcd** — cluster state storage If any pod is not in `Running` state, wait a minute and check again. Some components take a moment to pull their container images and start up. ## Step 6: Deploy a Test Workload With the cluster running, deploy a simple nginx web server to confirm everything works end to end: ```bash kubectl create deployment nginx --image=nginx:latest --replicas=2 ``` This creates a Deployment with two nginx pods. Check that the pods are running: ```bash kubectl get pods ``` Both pods should reach `Running` status within 30 seconds. On a single-node cluster, both pods run on the same node — this is expected. Expose the deployment as a NodePort service so you can access it from outside the cluster: ```bash kubectl expose deployment nginx --port=80 --type=NodePort ``` Find the assigned NodePort: ```bash kubectl get svc nginx ``` The output will show a port mapping like `80:31234/TCP`. The number after the colon (31234 in this example) is the NodePort. Access the nginx welcome page using your server’s IP and this port: ```bash NODE_PORT=$(kubectl get svc nginx -o jsonpath='{.spec.ports[0].nodePort}') curl http://YOUR_SERVER_IP:${NODE_PORT} ``` You should see the default nginx welcome page HTML. This confirms that the cluster is running, pod networking works, and services are correctly routing traffic from the node to the pods. > **Tip:** In a production setup, you would use three control plane nodes for high availability. A single control plane node is fine for development and learning, but a failure of that node means the entire cluster is unavailable. See [Provisioning Bare Metal Kubernetes with KubeOne and Terraform](/learn/kubeone/bare-metal-kubernetes-terraform/) for a full HA setup. ## Step 7: Understand the KubeOne Workflow Now that you have a running cluster, it is worth understanding how KubeOne manages it going forward. This is where KubeOne differs from tools that only handle initial installation. ### Idempotent Apply KubeOne uses an **idempotent apply model**. You can run `kubeone apply` as many times as you want, and it will converge to the desired state described in your manifest. If the cluster already matches the manifest, KubeOne does nothing. If something has drifted — a different Kubernetes version, a missing component, a misconfigured setting — KubeOne fixes it. This means your manifest is always the source of truth. Change the manifest, run apply, and KubeOne figures out what needs to happen. ### Upgrading Kubernetes To upgrade your cluster to a newer Kubernetes version, edit `kubeone.yaml` and change the version: ```yaml versions: kubernetes: "v1.31.0" ``` Then run: ```bash kubeone apply --manifest kubeone.yaml ``` KubeOne handles the upgrade process: it drains the node, upgrades the control plane components, upgrades kubelet, and uncordons the node. For multi-node clusters, it performs this as a rolling upgrade — one node at a time — to maintain availability. ### Checking Cluster Status To see the current state of your cluster without making any changes: ```bash kubeone status --manifest kubeone.yaml ``` This reports the Kubernetes version running on each node, node health, and whether the cluster matches the manifest. ### Tearing Down the Cluster If you want to remove the cluster entirely: ```bash kubeone reset --manifest kubeone.yaml ``` > **Warning:** `kubeone reset` destroys the cluster and removes all Kubernetes components from the server. All workloads, data, and configuration are lost. The server itself is not deleted — only the Kubernetes installation is removed. Use this with caution. ## Troubleshooting Common Issues ### SSH connection timeout Verify that the server’s firewall allows inbound SSH on port 22. Double-check that the SSH key path in your manifest matches an authorized key on the server. Run the SSH command from Step 2 manually to isolate the issue. ### Cluster provisioning fails at container runtime KubeOne needs to pull container images from the internet during provisioning. If your server is behind a corporate proxy or has restricted outbound access, configure the proxy settings in the KubeOneCluster manifest under the `proxy` section: ```yaml proxy: http: "http://proxy.example.com:8080" https: "http://proxy.example.com:8080" noProxy: "localhost,127.0.0.1,10.0.0.0/8" ``` ### kubectl cannot connect after provisioning Make sure the server’s firewall allows inbound traffic on port 6443, which is the Kubernetes API server port. If you are using a cloud provider, check the security group or firewall rules attached to the VM. Also verify that the `publicAddress` in your manifest is the correct IP. ### Pods stuck in Pending state On a single-node setup, the control plane node must also run regular workloads. KubeOne removes the default control plane taint for single-node clusters, but if pods remain in Pending state, inspect the node for issues: ```bash kubectl describe node ``` Look for conditions like `DiskPressure`, `MemoryPressure`, or `PIDPressure`. These indicate the server does not have enough resources. For a single-node cluster running test workloads, 2 vCPU and 4 GB RAM is the minimum — more is better. ## Clean Up If you are done experimenting and want to clean up: ```bash kubeone reset --manifest kubeone.yaml ``` This removes Kubernetes from the server. If you created a cloud VM specifically for this tutorial, delete it through your cloud provider’s console or CLI to stop incurring charges. ## Next Steps You now have the foundation to work with KubeOne. Here is where to go from here: - [**KubeOne with Terraform: Infrastructure as Code for Kubernetes**](/learn/kubeone/kubeone-terraform-iac/) — the next tutorial in this series, covering how to use Terraform to provision infrastructure and feed it into KubeOne automatically. - [**Provisioning Bare Metal Kubernetes with KubeOne and Terraform**](/learn/kubeone/bare-metal-kubernetes-terraform/) — a full high-availability production setup with three control plane nodes and worker nodes. - [**Deploying KubeOne Clusters on Hetzner Cloud**](/learn/kubeone/kubeone-hetzner-cloud/) — a cost-effective cloud setup using Hetzner’s infrastructure with Terraform integration. ## Summary You installed KubeOne, created a KubeOneCluster manifest targeting a single server, and provisioned a working Kubernetes cluster in minutes. KubeOne handled the container runtime installation, kubeadm bootstrapping, CNI configuration, and kubeconfig generation — all from one command. The key takeaway is KubeOne’s workflow: describe the desired state in a YAML manifest, run `kubeone apply`, and KubeOne makes it happen. The same command handles initial installation, configuration changes, and Kubernetes version upgrades. This is the pattern you will use whether you are managing one node for development or fifty nodes across multiple data centers. #### Resources - [KubeOne Documentation](https://docs.kubermatic.com/kubeone/) - [KubeOne GitHub Repository](https://github.com/kubermatic/kubeone) - [KubeOne Terraform Examples](https://github.com/kubermatic/kubeone/tree/main/examples/terraform) #### On This Page - [Introduction](#introduction) - [Step 1: Install KubeOne](#step-1-install-kubeone) - [Step 2: Prepare Your Server](#step-2-prepare-your-server) - [Step 3: Create the KubeOneCluster Manifest](#step-3-create-the-kubeonecluster-manifest) - [Step 4: Provision the Cluster](#step-4-provision-the-cluster) - [Step 5: Access Your Cluster](#step-5-access-your-cluster) - [Step 6: Deploy a Test Workload](#step-6-deploy-a-test-workload) - [Step 7: Understand the KubeOne Workflow](#step-7-understand-the-kubeone-workflow) - [Idempotent Apply](#idempotent-apply) - [Upgrading Kubernetes](#upgrading-kubernetes) - [Checking Cluster Status](#checking-cluster-status) - [Tearing Down the Cluster](#tearing-down-the-cluster) - [Troubleshooting Common Issues](#troubleshooting-common-issues) - [SSH connection timeout](#ssh-connection-timeout) - [Cluster provisioning fails at container runtime](#cluster-provisioning-fails-at-container-runtime) - [kubectl cannot connect after provisioning](#kubectl-cannot-connect-after-provisioning) - [Pods stuck in Pending state](#pods-stuck-in-pending-state) - [Clean Up](#clean-up) - [Next Steps](#next-steps) - [Summary](#summary) --- ## Installing KubeVirt on a Kubernetes Cluster - **URL:** https://www.kubermatic.com/learn/kubevirt/installing-kubevirt/ - **Date:** 2026-04-30 [Learn](/learn/) / [Kubevirt](/learn/kubevirt/) / Installing KubeVirt on a Kubernetes Cluster kubevirt # Installing KubeVirt on a Kubernetes Cluster ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Mar 17, 2026 14 min read Beginner [getting-started](/learn/?tag=getting-started) [virtualization](/learn/?tag=virtualization) #### Prerequisites - A running Kubernetes cluster (v1.28 or later) - kubectl configured with cluster-admin access - Nodes with hardware virtualization support (Intel VT-x or AMD-V) - Basic understanding of KubeVirt concepts — see [What is KubeVirt?](/learn/kubevirt/what-is-kubevirt/) ## Introduction You have a Kubernetes cluster running your containerized workloads. Now you want to add virtual machines to the mix — maybe you have legacy applications that need a full OS, or you are evaluating a migration path away from VMware. Either way, you need KubeVirt installed and working. In this tutorial, you will install KubeVirt and the Containerized Data Importer (CDI) on an existing Kubernetes cluster, set up the `virtctl` command-line tool, and launch your first virtual machine to verify that everything works. By the end, you will have a fully functional KubeVirt installation with a running VM that you can access via console. The whole process takes about 20 minutes if your cluster is already up. Most of that time is waiting for pods to pull images and reach a running state. Here is what you will set up: - **KubeVirt operator and custom resource** — the core virtualization layer - **Containerized Data Importer (CDI)** — for importing disk images into PersistentVolumes - **virtctl CLI** — the command-line tool for VM-specific operations - **A test VM** — to prove everything works end to end ## Step 1: Verify Hardware Virtualization Support Before installing anything, you need to confirm that your cluster nodes support hardware virtualization. KubeVirt uses KVM under the hood, and KVM requires either Intel VT-x or AMD-V extensions at the CPU level. If you have SSH access to a cluster node, run this command: ```bash grep -cE 'vmx|svm' /proc/cpuinfo ``` The output is a number. If it is greater than 0, hardware virtualization is available. The number itself tells you how many CPU cores support it — on a 4-core machine with VT-x enabled, you would see `4`. If the output is `0`, your CPU either does not support virtualization or it is disabled. On physical servers, check the BIOS/UEFI settings — hardware virtualization is sometimes disabled by default. On cloud VMs, you need an instance type that supports nested virtualization. If you cannot SSH into your nodes directly, you can check from within the cluster by running a privileged pod: ```bash kubectl run virt-check --image=alpine --restart=Never --rm -it \ --overrides='{"spec":{"containers":[{"name":"virt-check","image":"alpine","command":["sh","-c","grep -cE vmx\\|svm /proc/cpuinfo"],"securityContext":{"privileged":true}}]}}' \ -- sh -c "grep -cE 'vmx|svm' /proc/cpuinfo" ``` You can also verify that the `/dev/kvm` device exists on the node: ```bash kubectl run kvm-check --image=alpine --restart=Never --rm -it \ --overrides='{"spec":{"containers":[{"name":"kvm-check","image":"alpine","command":["ls","-la","/dev/kvm"],"securityContext":{"privileged":true}}]}}' \ -- ls -la /dev/kvm ``` If `/dev/kvm` exists, you are good to go. > **Warning:** KubeVirt can fall back to software emulation when hardware virtualization is not available, but the performance penalty is severe — expect 10x to 100x slower execution. Software emulation is acceptable for quick testing or development environments where you just need to validate manifests and workflows. It is not viable for production workloads or any scenario where VM performance matters. If you are deploying to cloud VMs, check your provider’s documentation for instance types that support nested virtualization (for example, `.metal` instances on AWS, or N2/C2 instances with nested virt enabled on GCP). ## Step 2: Deploy the KubeVirt Operator With hardware virtualization confirmed, you can install KubeVirt. The installation follows the standard Kubernetes operator pattern: first you deploy the operator, then you create a custom resource that tells the operator what to deploy. ``` flowchart LR A["kubectl create kubevirt-operator.yaml"] --> B[virt-operator pod running] B -->|waits for| C["kubectl apply KubeVirt CR"] C --> D[virt-operator reconciles] D --> E[virt-api Deployment] D --> F[virt-controller Deployment] D --> G[virt-handler DaemonSet] ``` Start by fetching the latest stable version and deploying the operator: ```bash export KUBEVIRT_VERSION=$(curl -s https://api.github.com/repos/kubevirt/kubevirt/releases/latest | grep tag_name | cut -d '"' -f 4) echo "Installing KubeVirt ${KUBEVIRT_VERSION}" kubectl create -f "https://github.com/kubevirt/kubevirt/releases/download/${KUBEVIRT_VERSION}/kubevirt-operator.yaml" ``` This creates several resources in the `kubevirt` namespace: - The `kubevirt` namespace itself - Custom Resource Definitions (CRDs) for VirtualMachine, VirtualMachineInstance, and related types - The `virt-operator` Deployment, which is the control plane component that manages all other KubeVirt components - ServiceAccounts, ClusterRoles, and ClusterRoleBindings for the operator’s RBAC permissions The operator does not deploy any VM-related components yet. It sits and waits for you to create a `KubeVirt` custom resource — that is the signal to roll out the full stack. This two-phase approach gives you the chance to customize the configuration before anything else gets deployed. Wait for the operator pod to be ready before proceeding: ```bash kubectl -n kubevirt wait --for=condition=Ready pod -l kubevirt.io=virt-operator --timeout=180s ``` ## Step 3: Create the KubeVirt Custom Resource Now create the `KubeVirt` custom resource that tells the operator to deploy all the components: ```yaml apiVersion: kubevirt.io/v1 kind: KubeVirt metadata: name: kubevirt namespace: kubevirt spec: certificateRotateStrategy: {} configuration: developerConfiguration: useEmulation: false customizeComponents: {} imagePullPolicy: IfNotPresent ``` Save this as `kubevirt-cr.yaml` and apply it: ```bash kubectl apply -f kubevirt-cr.yaml ``` > **Tip:** If your nodes do not have hardware virtualization support and you want to proceed with software emulation for testing purposes, change `useEmulation: false` to `useEmulation: true` in the manifest above. Remember that this is only suitable for development and testing — never for production. Once you apply this resource, the virt-operator reads it and begins deploying the KubeVirt components: - **virt-api** — a Deployment that provides the Kubernetes API extension for VM operations. It handles subresource requests like console access, VNC, and migration triggers. It also performs admission validation on VM manifests before they are persisted. - **virt-controller** — a Deployment that watches for VirtualMachine and VirtualMachineInstance resources. When you create a VM, virt-controller creates the corresponding virt-launcher pod and coordinates the VM lifecycle at the cluster level. - **virt-handler** — a DaemonSet that runs on every node eligible to host VMs. It is the node-level agent that manages the actual KVM/libvirt interaction. When a virt-launcher pod lands on a node, virt-handler configures and starts the VM process inside it. Each VM runs inside its own virt-launcher pod. The pod provides the isolation boundary — cgroups, namespaces, resource limits — while the actual VM process runs as a QEMU/KVM instance managed by libvirt inside that pod. ## Step 4: Wait for KubeVirt to Deploy The operator needs a few minutes to pull images and bring all components online. Use the built-in condition check to wait: ```bash kubectl -n kubevirt wait kv kubevirt --for condition=Available --timeout=300s ``` When this command returns successfully, KubeVirt is ready. If it times out, check the operator logs for errors: ```bash kubectl -n kubevirt logs -l kubevirt.io=virt-operator --tail=50 ``` Verify that all pods are running: ```bash kubectl get pods -n kubevirt ``` You should see output similar to this: ``` NAME READY STATUS RESTARTS AGE virt-api-7fc5db8b6-4xz8m 1/1 Running 0 2m virt-api-7fc5db8b6-n9hkl 1/1 Running 0 2m virt-controller-6b9f5d4c7-8qjrw 1/1 Running 0 2m virt-controller-6b9f5d4c7-txz5k 1/1 Running 0 2m virt-handler-7kpnz 1/1 Running 0 2m virt-handler-qm4x8 1/1 Running 0 2m virt-operator-5f8bc4c5d-jn7xr 1/1 Running 0 4m virt-operator-5f8bc4c5d-zw2lp 1/1 Running 0 4m ``` The exact pod names will differ, and the number of virt-handler pods matches the number of nodes in your cluster (since it is a DaemonSet). The key thing is that all pods show `Running` with `1/1` ready. You can also check the KubeVirt resource status directly: ```bash kubectl get kubevirt -n kubevirt ``` The `PHASE` column should show `Deployed`. ## Step 5: Install the Containerized Data Importer (CDI) KubeVirt handles running VMs. But VMs need disk images — ISOs, QCOW2 files, VMDKs — and those images need to get into PersistentVolumes that the VMs can mount. That is where the Containerized Data Importer comes in. CDI is a separate project that works alongside KubeVirt. It provides a declarative way to import VM disk images from various sources (HTTP endpoints, container registries, S3 buckets, or local uploads) into PersistentVolumeClaims. Without CDI, you would need to manually provision and populate PVCs before creating VMs — CDI automates that entire workflow. Install CDI the same way you installed KubeVirt — operator first, then custom resource: ```bash export CDI_VERSION=$(curl -s https://api.github.com/repos/kubevirt/containerized-data-importer/releases/latest | grep tag_name | cut -d '"' -f 4) echo "Installing CDI ${CDI_VERSION}" kubectl create -f "https://github.com/kubevirt/containerized-data-importer/releases/download/${CDI_VERSION}/cdi-operator.yaml" kubectl create -f "https://github.com/kubevirt/containerized-data-importer/releases/download/${CDI_VERSION}/cdi-cr.yaml" ``` The first command deploys the CDI operator. The second creates the `CDI` custom resource in the `cdi` namespace, which triggers the operator to deploy all CDI components. Wait for CDI to become available: ```bash kubectl wait --for=condition=Available --timeout=300s cdi/cdi -n cdi ``` Verify the CDI pods are running: ```bash kubectl get pods -n cdi ``` You should see the CDI operator, API server, deployment, and upload proxy pods all in a `Running` state. CDI becomes important when you start working with real VM images — importing cloud images from public URLs, converting VMDK files from VMware exports, or cloning existing disks. For this tutorial’s test VM, you will use a container disk that does not require CDI, but having CDI installed means you are ready for real workloads. ## Step 6: Install virtctl `virtctl` is the KubeVirt command-line tool that handles VM-specific operations that `kubectl` cannot do natively. You need it for: - Accessing a VM’s serial console or VNC display - Starting and stopping VMs - Live migrating VMs between nodes - Port forwarding to VM ports - SSH access to VMs - Uploading disk images Install it by downloading the binary that matches your KubeVirt version: ```bash curl -L -o virtctl "https://github.com/kubevirt/kubevirt/releases/download/${KUBEVIRT_VERSION}/virtctl-${KUBEVIRT_VERSION}-linux-amd64" chmod +x virtctl sudo mv virtctl /usr/local/bin/ ``` For macOS, replace `linux-amd64` with `darwin-amd64` (Intel) or `darwin-arm64` (Apple Silicon): ```bash curl -L -o virtctl "https://github.com/kubevirt/kubevirt/releases/download/${KUBEVIRT_VERSION}/virtctl-${KUBEVIRT_VERSION}-darwin-arm64" chmod +x virtctl sudo mv virtctl /usr/local/bin/ ``` Verify the installation: ```bash virtctl version ``` If you prefer managing kubectl plugins through krew, you can install virtctl as a kubectl plugin instead: ```bash kubectl krew install virt ``` This lets you use `kubectl virt` instead of `virtctl` — the functionality is identical. Both approaches work; pick whichever fits your workflow. ## Step 7: Launch Your First Virtual Machine Time to verify the installation by running an actual VM. You will use a CirrOS container disk — a minimal Linux distribution designed specifically for cloud testing. The container disk approach packages a VM image inside a container image, so there is no need to provision storage or import disk images. It is the fastest way to get a VM running for validation purposes. Create a file called `testvm.yaml` with the following content: ```yaml apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: testvm spec: running: true template: metadata: labels: kubevirt.io/vm: testvm spec: domain: devices: disks: - name: containerdisk disk: bus: virtio - name: cloudinitdisk disk: bus: virtio interfaces: - name: default masquerade: {} resources: requests: memory: 1Gi networks: - name: default pod: {} volumes: - name: containerdisk containerDisk: image: quay.io/kubevirt/cirros-container-disk-demo - name: cloudinitdisk cloudInitNoCloud: userDataBase64: SGVsbG8sIFdvcmxkIQ== ``` Apply it: ```bash kubectl apply -f testvm.yaml ``` A few things to understand about this manifest: - **`spec.running: true`** tells KubeVirt to start the VM immediately after creation. If you set this to `false`, the VirtualMachine resource is created but the VM does not boot until you explicitly start it with `virtctl start testvm`. - **`containerDisk`** is a volume type that pulls a VM disk image packaged as a container image. The image `quay.io/kubevirt/cirros-container-disk-demo` contains a CirrOS disk image. Container disks are ephemeral — any data written inside the VM is lost when the VM is deleted. They are ideal for testing and stateless workloads. - **`cloudInitNoCloud`** provides basic cloud-init configuration. The base64-encoded value here decodes to “Hello, World!” — a minimal user data payload. In production VMs, you would use this to inject SSH keys, configure networking, install packages, and run setup scripts. - **`masquerade` networking** uses NAT to connect the VM to the pod network. The VM gets an internal IP address and can reach external services. Incoming connections require explicit port forwarding or a Kubernetes Service. - **`bus: virtio`** specifies paravirtualized disk controllers, which offer significantly better I/O performance than emulated IDE or SATA controllers. CirrOS includes virtio drivers by default. Windows VMs may need virtio drivers installed separately. Watch the VM come up: ```bash kubectl get vmi -w ``` The VirtualMachineInstance (VMI) will transition through several phases: `Pending`, `Scheduling`, `Scheduled`, and finally `Running`. Once you see `Running`, the VM is booted and ready. You can also check the virt-launcher pod that hosts the VM: ```bash kubectl get pods -l kubevirt.io/vm=testvm ``` ## Step 8: Access the VM Console With the VM running, connect to its serial console: ```bash virtctl console testvm ``` You will see the CirrOS boot output, followed by a login prompt. Log in with the default credentials: - **Username:** `cirros` - **Password:** `gocubsgo` Once logged in, run a few commands to confirm the VM is functioning: ```bash hostname ip addr uname -a ``` You should see the hostname set to `testvm`, a network interface with an IP address from the VM’s internal network, and the Linux kernel version that CirrOS ships with. To exit the console, press `Ctrl+]`. You can also access the VM’s graphical console through VNC if needed: ```bash virtctl vnc testvm ``` This opens a VNC viewer if one is installed on your local machine. For a headless CirrOS VM this is not particularly useful, but it becomes valuable when working with desktop operating systems or VMs with graphical installers. ## Step 9: Clean Up Once you have verified that the VM works, clean it up: ```bash kubectl delete vm testvm ``` This deletes both the VirtualMachine resource and the associated VirtualMachineInstance. The virt-launcher pod is terminated and the container disk is released. > **Tip:** Deleting a VirtualMachine also deletes the associated VirtualMachineInstance and stops the VM. If you only want to stop the VM without deleting the definition, use `virtctl stop testvm` instead. You can then start it again later with `virtctl start testvm`. This is analogous to shutting down vs. destroying a VM in traditional hypervisors — the “hardware definition” persists even when the VM is powered off. If you want to remove the entire KubeVirt installation later (not recommended if you plan to continue with the series), the removal order matters — delete the custom resources first, then the operators: ```bash kubectl delete -f kubevirt-cr.yaml kubectl delete -f "https://github.com/kubevirt/kubevirt/releases/download/${KUBEVIRT_VERSION}/kubevirt-operator.yaml" kubectl delete -f "https://github.com/kubevirt/containerized-data-importer/releases/download/${CDI_VERSION}/cdi-cr.yaml" kubectl delete -f "https://github.com/kubevirt/containerized-data-importer/releases/download/${CDI_VERSION}/cdi-operator.yaml" ``` ## Troubleshooting Common Installation Issues If something went wrong during the installation, here are the most common issues and how to resolve them. ### KVM device not found If virt-handler pods fail with errors about `/dev/kvm` not being found, the node does not have hardware virtualization available. Verify that: 1. The physical CPU supports Intel VT-x or AMD-V 2. Virtualization is enabled in the BIOS/UEFI 3. If running on cloud VMs, nested virtualization is enabled for the instance type 4. The KVM kernel modules are loaded: `lsmod | grep kvm` As a temporary workaround for testing, you can edit the KubeVirt custom resource to enable software emulation: ```bash kubectl edit kubevirt kubevirt -n kubevirt ``` Set `spec.configuration.developerConfiguration.useEmulation` to `true`. The operator will reconfigure the components automatically. ### Pods stuck in Pending If KubeVirt pods remain in `Pending` state, the most common causes are: - **Insufficient resources** — virt-handler and virt-launcher pods have resource requests. Check that your nodes have enough CPU and memory available with `kubectl describe nodes`. - **Resource quotas** — if your namespace has ResourceQuotas configured, they may block pod creation. Check with `kubectl get resourcequota -n kubevirt`. - **Node taints** — virt-handler is a DaemonSet that needs to run on worker nodes. If your nodes have taints, you may need to add tolerations to the KubeVirt configuration. - **PodSecurityPolicy or PodSecurity admission** — virt-handler requires privileged access. If your cluster enforces pod security standards, you may need to configure exemptions for the `kubevirt` namespace. ### CDI importer pod errors If CDI data import pods fail, check these common causes: - **No default StorageClass** — CDI needs to create PersistentVolumeClaims dynamically. Verify you have a default StorageClass: `kubectl get storageclass`. One should be marked `(default)`. - **Insufficient storage** — CDI creates scratch space PVCs during import operations. Ensure your storage backend has enough capacity. - **Network restrictions** — if importing images from external URLs, the CDI importer pods need outbound network access. Check network policies that might block egress traffic from the `cdi` namespace. ### virt-operator CrashLoopBackOff If the virt-operator itself is crashing, check the logs: ```bash kubectl -n kubevirt logs -l kubevirt.io=virt-operator --previous ``` Common causes include RBAC misconfigurations (especially on clusters with strict security policies) and incompatibilities between the KubeVirt version and the Kubernetes version. Check the [KubeVirt releases page](https://github.com/kubevirt/kubevirt/releases) for the compatibility matrix. ## What You Installed Here is a quick recap of what is now running on your cluster: | Component | Type | Namespace | Purpose | |-----------------|------------|-----------|------------------------------------------| | virt-operator | Deployment | kubevirt | Manages KubeVirt component lifecycle | | virt-api | Deployment | kubevirt | API extension for VM operations | | virt-controller | Deployment | kubevirt | Cluster-level VM lifecycle controller | | virt-handler | DaemonSet | kubevirt | Node-level VM management agent | | cdi-operator | Deployment | cdi | Manages CDI component lifecycle | | cdi-apiserver | Deployment | cdi | API extension for data import operations | | cdi-deployment | Deployment | cdi | Core CDI controller | | cdi-uploadproxy | Deployment | cdi | Handles local disk image uploads | ## Next Steps Your cluster can now run virtual machines alongside containers. Here is where to go from here: - [Creating and Managing Your First VM with KubeVirt](/learn/kubevirt/creating-managing-vms/) (coming soon) — the next tutorial in this series, where you will work with persistent storage, cloud images, and more realistic VM configurations - [Planning Your VMware to KubeVirt Migration](/learn/kubevirt/vmware-to-kubevirt-migration-planning/) — if you are evaluating KubeVirt as a VMware replacement, this guide covers the planning and assessment phase - [Troubleshooting KubeVirt](/learn/kubevirt/troubleshooting-kubevirt/) — a reference for diagnosing and resolving common KubeVirt issues in production ## Summary You installed KubeVirt and the Containerized Data Importer on a Kubernetes cluster, set up the `virtctl` CLI tool, and launched a test virtual machine using a CirrOS container disk. You verified that the VM booted correctly by accessing its serial console. Your cluster is now capable of running virtual machines alongside containers, managed through the same Kubernetes API and tooling. The KubeVirt operator handles component lifecycle, CDI is ready to import disk images when you need persistent VM storage, and `virtctl` gives you the CLI tools for day-to-day VM operations. In the next tutorial, you will move beyond test VMs and create a production-style virtual machine with persistent storage, proper networking, and cloud-init configuration. #### Resources - [KubeVirt Installation Guide](https://kubevirt.io/user-guide/cluster_admin/installation/) - [KubeVirt Releases](https://github.com/kubevirt/kubevirt/releases) - [CDI Installation](https://github.com/kubevirt/containerized-data-importer/releases) #### On This Page - [Introduction](#introduction) - [Step 1: Verify Hardware Virtualization Support](#step-1-verify-hardware-virtualization-support) - [Step 2: Deploy the KubeVirt Operator](#step-2-deploy-the-kubevirt-operator) - [Step 3: Create the KubeVirt Custom Resource](#step-3-create-the-kubevirt-custom-resource) - [Step 4: Wait for KubeVirt to Deploy](#step-4-wait-for-kubevirt-to-deploy) - [Step 5: Install the Containerized Data Importer (CDI)](#step-5-install-the-containerized-data-importer-cdi) - [Step 6: Install virtctl](#step-6-install-virtctl) - [Step 7: Launch Your First Virtual Machine](#step-7-launch-your-first-virtual-machine) - [Step 8: Access the VM Console](#step-8-access-the-vm-console) - [Step 9: Clean Up](#step-9-clean-up) - [Troubleshooting Common Installation Issues](#troubleshooting-common-installation-issues) - [KVM device not found](#kvm-device-not-found) - [Pods stuck in Pending](#pods-stuck-in-pending) - [CDI importer pod errors](#cdi-importer-pod-errors) - [virt-operator CrashLoopBackOff](#virt-operator-crashloopbackoff) - [What You Installed](#what-you-installed) - [Next Steps](#next-steps) - [Summary](#summary) --- ## kcp Workspaces vs Namespaces vs vcluster - **URL:** https://www.kubermatic.com/learn/kcp/workspaces-vs-namespaces-vs-vcluster/ - **Date:** 2026-04-30 [Learn](/learn/) / [Kcp](/learn/kcp/) / kcp Workspaces vs Namespaces vs vcluster kcp # kcp Workspaces vs Namespaces vs vcluster ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Mar 17, 2026 13 min read Beginner [comparison](/learn/?tag=comparison) [platform-engineering](/learn/?tag=platform-engineering) [multi-tenancy](/learn/?tag=multi-tenancy) #### Prerequisites - Basic understanding of Kubernetes namespaces and RBAC - Familiarity with the concept of multi-tenancy ## Introduction Every platform team hits the same question: how do you give multiple teams isolated Kubernetes environments without spinning up a cluster per team? Dedicated clusters provide maximum isolation, but you end up managing infrastructure that scales linearly with your team count. Share a single cluster, and you trade operational overhead for a different kind of pain — CRD conflicts, noisy neighbors, and RBAC rules that grow until nobody fully understands them. Three approaches have emerged to solve this problem, each with a fundamentally different architecture. **Namespaces** are built into Kubernetes and provide logical partitioning within a single cluster. **vcluster** creates virtual Kubernetes clusters that run as pods inside a host cluster. **kcp workspaces** provide API-only isolation — full Kubernetes API scopes without any compute layer attached. Each solves the multi-tenancy problem differently, with different trade-offs in isolation strength, resource overhead, and complexity. This guide compares all three so you can pick the right one for your situation. ## The Multi-Tenancy Problem You have 10 teams. Each wants their own Kubernetes “environment” where they can deploy applications, install operators, define custom resources, and operate independently. You have two obvious options. **Option 1: Give each team a dedicated cluster.** Maximum isolation, maximum cost. You are now managing 10 clusters, each with its own control plane, node pool, monitoring stack, upgrade cycle, and operational burden. When you have 50 teams, you have 50 clusters. The cost and operational complexity scale linearly. **Option 2: Share one cluster.** Save money, but teams step on each other. CRDs are cluster-scoped, so two teams cannot use different versions of the same custom resource definition. A runaway pod in one team’s namespace can starve nodes of memory and CPU, affecting everyone. RBAC rules for cluster-scoped resources become a tangled mess of ClusterRoles and ClusterRoleBindings. The three approaches below are all different answers to “how do we share without pain?” They sit on a spectrum from lightweight metadata boundaries (namespaces) to full virtual clusters (vcluster) to pure API isolation (kcp workspaces). ``` flowchart LR subgraph NS["Namespaces"] NS_API[Shared API Server] NS_CRD[Shared CRDs] NS_A["ns: team-a"] NS_B["ns: team-b"] NS_API --> NS_A NS_API --> NS_B end subgraph VC["vcluster"] Host[Host Cluster] VC_A["vcluster A own API + CRDs pods synced to host"] VC_B["vcluster B own API + CRDs pods synced to host"] Host --> VC_A Host --> VC_B end subgraph KCP["kcp Workspaces"] KCP_API[kcp API machinery] WS_A["workspace A own CRDs + RBAC"] WS_B["workspace B own CRDs + RBAC"] Operator[Multi-tenant operator] Compute[(Real k8s cluster)] KCP_API --> WS_A KCP_API --> WS_B WS_A -. APIBinding .-> Operator WS_B -. APIBinding .-> Operator Operator --> Compute end ``` ## Namespaces: The Built-In Approach ### How They Work Kubernetes namespaces are a built-in mechanism for dividing a single cluster into logical partitions. Each namespace gets its own set of resources — pods, services, configmaps, secrets — and its own RBAC rules. You control how much each namespace can consume using ResourceQuotas and LimitRanges. NetworkPolicies can restrict traffic between namespaces. Every Kubernetes cluster ships with namespaces. No additional installation, no extra processes, no third-party dependencies. You create a namespace with `kubectl create namespace team-a`, set up some RBAC rules, apply a ResourceQuota, and hand the team a kubeconfig scoped to that namespace. ### Strengths **Zero additional tooling.** Namespaces are part of every Kubernetes distribution. They work on EKS, GKE, AKS, KubeOne-managed clusters, and bare metal setups. There is nothing to install. **Low overhead.** A namespace is a metadata boundary, not a running process. Creating 100 namespaces does not add 100 API servers or 100 etcd instances. The cluster’s resource consumption stays the same whether you have 5 namespaces or 500. **Well-understood by every Kubernetes user.** Anyone who has used Kubernetes has worked with namespaces. The mental model is simple, the documentation is extensive, and troubleshooting is straightforward. **Works well for trusted teams.** If your teams are all part of the same organization, trust each other, and run similar workloads, namespaces provide enough separation without adding complexity. ### Limitations **CRDs are cluster-scoped.** Install a CRD in one namespace and every namespace sees it. Two teams cannot use different versions of the same CRD. If team A needs cert-manager v1.12 and team B needs v1.14, you have a conflict that namespaces cannot resolve. **Noisy neighbor risk.** A pod in namespace A that consumes all node memory affects pods in namespace B. ResourceQuotas limit what a namespace can *request*, but they do not prevent a single pod from exceeding its limits and triggering OOM kills that impact the entire node. **RBAC gets complex fast.** Cluster-scoped resources — nodes, persistent volumes, CRDs, cluster roles — require careful RBAC rules to prevent cross-tenant access. As the number of namespaces grows, the number of RBAC rules grows faster. A mistake in a ClusterRoleBinding can expose resources across all namespaces. **No true API isolation.** All namespaces share the same API server, the same etcd, the same admission webhooks. A misbehaving admission webhook affects every namespace. A slow custom controller watching all namespaces impacts the API server for everyone. **Best for:** Small teams, trusted environments, simple applications where CRD conflicts are unlikely. ## vcluster: Virtual Clusters ### How They Work vcluster, created by Loft Labs, creates virtual Kubernetes clusters that run inside pods on a host cluster. Each vcluster has its own API server — based on k3s, k0s, or vanilla Kubernetes — and its own backing store (etcd or SQLite). From the tenant’s perspective, they have a full Kubernetes cluster with cluster-admin access. From the host cluster’s perspective, a vcluster is just a set of pods running in a namespace. The key mechanism is the **syncer**. When a tenant creates a pod in their vcluster, the syncer translates it into a real pod on the host cluster. The pod runs on the host cluster’s nodes, consuming the host cluster’s compute resources. Services, endpoints, and other resources are synced bidirectionally between the vcluster and the host. You install a vcluster with a single Helm chart. Within 30 to 60 seconds, you have a fully functional virtual cluster with its own kubeconfig. ### Strengths **Strong isolation.** Each tenant gets their own API server, their own set of CRDs, and their own admission configuration. Two tenants can run completely different CRD versions, different operators, and different webhook configurations without any conflict. **Tenants get full cluster-admin access.** Unlike namespaces, where tenants are limited to namespace-scoped operations, vcluster tenants can create ClusterRoles, install CRDs, and configure cluster-level settings within their virtual cluster. **Fast creation.** Spinning up a new vcluster takes 30 to 60 seconds. This makes vclusters particularly effective for CI/CD pipelines where you need an isolated cluster for each test run. **Real kubeconfig.** Tenants receive a standard kubeconfig that works with kubectl, Helm, ArgoCD, and every other Kubernetes tool. No special client-side tooling is required. ### Limitations **Resource overhead.** Each vcluster runs an API server and a syncer pod. With 50 vclusters, that is 50 API servers consuming memory and CPU on the host cluster. The per-tenant overhead is modest (around 200-500 MB of memory per vcluster), but it adds up at scale. **Compute is still shared.** The host cluster runs all workloads from all vclusters. A vcluster tenant cannot consume more resources than their quota on the host cluster allows. Node-level isolation between tenants requires additional tooling like node affinity rules or dedicated node pools. **Networking complexity.** The syncer translates services and endpoints between the virtual and host clusters. This translation layer can introduce latency and makes network debugging harder. If a service is not reachable, you need to check both the vcluster and the host cluster to diagnose the issue. **Commercial components.** The open-source vcluster is fully functional for basic use cases. The full platform — vCluster Platform (formerly Loft) — adds features like sleep mode, access control, and cost management, but it is a commercial product with a licensing cost. **Best for:** CI/CD environments (ephemeral clusters for testing), teams that need cluster-admin access, organizations with moderate tenant counts (10-50). ## kcp Workspaces: API-Only Isolation ### How They Work kcp provides workspaces — isolated API scopes that function like independent Kubernetes clusters. Each workspace has its own resources, CRDs, RBAC rules, and admission configuration. You interact with a workspace using standard kubectl commands, and it feels exactly like interacting with a regular Kubernetes cluster. The fundamental difference between kcp and both namespaces and vcluster is that kcp has no compute layer. There are no pods, no nodes, no scheduler, and no container runtime. kcp is pure API machinery — the Kubernetes control plane stripped down to CRDs, RBAC, admission control, and resource management. When actual compute is needed, an API provider runs a **multi-tenant operator** that watches across the workspaces bound to its `APIExport` and reconciles resources into a real backend — one or more physical Kubernetes clusters, a cloud provider API, or any other system the operator understands. Earlier versions of kcp shipped a Syncer and Transparent Multi-Cluster (TMC) code for workload scheduling, but [both were removed in May 2023](https://github.com/kcp-dev/kcp) to refocus the project on pure API management. Compute lives with the operator, not with kcp itself. ### Strengths **True API isolation with minimal overhead.** Workspaces are API scopes in a shared control plane, not running processes. Creating a new workspace is almost free in terms of resource consumption. A single kcp instance can host thousands of workspaces on modest hardware. **CRD isolation.** Each workspace has its own CRD registry. Two workspaces can define completely different versions of the same CRD without any conflict. This is the same benefit vcluster provides, but without the per-tenant API server overhead. **Hierarchical workspaces.** Workspaces can contain child workspaces, enabling organizational hierarchy. A top-level workspace for a business unit can contain child workspaces for each team, which can contain child workspaces for each environment. Policies and configurations can cascade down the hierarchy. **API sharing via APIExport and APIBinding.** Service teams can publish APIs using APIExport, and other workspaces can consume those APIs using APIBinding. This creates a native service catalog mechanism. A database team can export a `Database` API, and application teams can bind to it and create database instances without understanding the underlying implementation. **Scales to thousands of tenants.** Since workspaces do not run compute, the control plane can manage far more tenants than vcluster. The limiting factor is the kcp server’s capacity to serve API requests, not the aggregate memory consumption of per-tenant API servers. ### Limitations **No native compute.** kcp does not run workloads by itself. You need a multi-tenant operator and at least one physical Kubernetes cluster (or equivalent backend) for actual pods. This adds architectural complexity — you are managing both a kcp control plane and the downstream compute that sits behind your APIs. **CNCF Sandbox maturity.** kcp is under active development. The API surface may change between releases. Production adoption requires careful evaluation and a willingness to track upstream changes. **Ecosystem tooling gaps.** Standard tools like Prometheus, ArgoCD, and Flux do not natively understand kcp workspaces yet. Observing state across workspaces and their downstream compute requires custom integration work. This gap will narrow over time, but today it means additional engineering effort. **Steeper learning curve.** The workspace, APIExport, and APIBinding model is new and unfamiliar to most Kubernetes users. Teams need to understand not just Kubernetes concepts, but also kcp-specific concepts like workspace hierarchies, multi-tenant operators, and API sharing. > **Warning:** kcp is a CNCF Sandbox project. Evaluate it carefully for production use. The APIExport and APIBinding mechanisms are still maturing, and breaking changes are possible between releases. **Best for:** Platform teams building Internal Developer Platforms, SaaS control planes, organizations with many tenants (100+) where compute isolation is less critical than API isolation. ## Head-to-Head Comparison | Factor | Namespaces | vcluster | kcp Workspaces | |-------------------------|--------------------------------|--------------------------------|----------------------------------------| | **Isolation Level** | Weak (shared API, shared CRDs) | Strong (separate API server) | Strong (separate API scope) | | **CRD Isolation** | No — cluster-scoped | Yes — per vcluster | Yes — per workspace | | **Resource Overhead** | None | Medium (API server per tenant) | Minimal (API scope only) | | **Compute Model** | Shared cluster | Shared cluster (synced) | External (via multi-tenant operator) | | **Tenant Count** | 10-50 practical | 10-100 practical | 100-1000+ practical | | **Tenant Admin Access** | Limited (namespace-scoped) | Full cluster-admin | Full workspace-admin | | **Tooling Maturity** | Built-in | Strong (Loft Labs ecosystem) | Early (CNCF Sandbox) | | **Setup Complexity** | None | Low (helm install) | Medium (kcp server + per-API operator) | | **Best Fit** | Trusted teams, simple apps | Dev/test, CI/CD | Platform engineering, SaaS | ## Decision Framework Use these questions to pick the right approach for your situation. **Start here: How many tenants do you have?** - **Under 10 tenants, trusted teams.** Namespaces are probably fine. Add ResourceQuotas and NetworkPolicies. Do not over-engineer it. - **10-50 tenants, need CRD isolation or cluster-admin.** vcluster gives you strong isolation with reasonable overhead. Especially good for CI/CD and ephemeral environments. - **50+ tenants, building a platform.** kcp workspaces scale better and provide API-level isolation without the per-tenant compute cost. Worth the investment if you are building an Internal Developer Platform. **Additional factors to consider:** - If tenants need to install their own operators, you need vcluster or kcp. Namespaces cannot provide CRD isolation. - If you need fast ephemeral environments for CI pipelines, vcluster’s 30-second spin-up time is hard to beat. - If you are building a service catalog with self-service APIs, kcp’s APIExport and APIBinding mechanism was designed for exactly this use case. - If you need proven, production-stable tooling today, vcluster has the most mature ecosystem. Fall back to namespaces if even vcluster feels like too much. > **Tip:** These approaches are not mutually exclusive. You can use namespaces within a kcp workspace, or run vclusters on clusters that are managed by kcp. Think of them as layers, not alternatives. ## Combining Approaches Real-world platforms often use multiple approaches together. Here are three patterns that work well in practice. **kcp for organizational isolation, namespaces for team separation.** Create one kcp workspace per business unit, giving each unit API-level isolation with its own CRDs and RBAC. Within each workspace, use namespaces for team-level separation. This gives you the scalability of kcp at the organization level with the simplicity of namespaces at the team level. **vcluster for ephemeral dev/test environments.** Run vclusters on a shared compute cluster managed by KubeOne or KKP. Developers spin up a vcluster for a feature branch, run their integration tests against it, and tear it down when the branch merges. The host cluster handles resource management and cost control. **Namespaces as a starting point, graduating to stronger isolation.** Start small teams with namespaces. When a team’s needs outgrow what namespaces can provide — they need their own CRDs, their own operators, or cluster-admin access — graduate them to a vcluster or a kcp workspace. This avoids over-engineering early while providing a clear growth path. ## Next Steps - [What is kcp?](/learn/kcp/what-is-kcp/) — learn the fundamentals of kcp and how it differs from Kubernetes - [Installing kcp and Creating Your First Workspace](/learn/kcp/installing-kcp-first-workspace/) — try kcp hands-on with a step-by-step guide - [vcluster Documentation](https://www.vcluster.com/docs) — explore the vcluster approach and try it on your own cluster ## Summary Namespaces provide basic isolation with zero overhead but break down when you hit CRD conflicts, noisy neighbor problems, or more than a few dozen tenants. vcluster gives each tenant a full virtual cluster with strong isolation, at the cost of per-tenant resource overhead that limits practical scale to roughly 100 tenants. kcp workspaces provide API-level isolation with minimal overhead, scaling to thousands of tenants, but require a separate compute layer and come with the trade-offs of a still-maturing project. Pick namespaces for simplicity when your teams trust each other and your tenant count is low. Pick vcluster when you need strong isolation with moderate scale, especially for CI/CD and development environments. Pick kcp when you are building an Internal Developer Platform or SaaS control plane that needs to serve many tenants without the per-tenant cost of running virtual clusters. The most important thing to remember is that these are not competing technologies. They operate at different layers of the stack and can be combined. Start with the simplest approach that meets your requirements today, and layer on stronger isolation as your platform grows. #### Resources - [kcp Documentation](https://docs.kcp.io/) - [vcluster Documentation](https://www.vcluster.com/docs) - [Kubernetes Namespaces Documentation](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) #### On This Page - [Introduction](#introduction) - [The Multi-Tenancy Problem](#the-multi-tenancy-problem) - [Namespaces: The Built-In Approach](#namespaces-the-built-in-approach) - [How They Work](#how-they-work) - [Strengths](#strengths) - [Limitations](#limitations) - [vcluster: Virtual Clusters](#vcluster-virtual-clusters) - [How They Work](#how-they-work-1) - [Strengths](#strengths-1) - [Limitations](#limitations-1) - [kcp Workspaces: API-Only Isolation](#kcp-workspaces-api-only-isolation) - [How They Work](#how-they-work-2) - [Strengths](#strengths-2) - [Limitations](#limitations-2) - [Head-to-Head Comparison](#head-to-head-comparison) - [Decision Framework](#decision-framework) - [Combining Approaches](#combining-approaches) - [Next Steps](#next-steps) - [Summary](#summary) --- ## KubeOne vs kOps: Which Should You Use? - **URL:** https://www.kubermatic.com/learn/kubeone/kubeone-vs-kops/ - **Date:** 2026-04-30 [Learn](/learn/) / [Kubeone](/learn/kubeone/) / KubeOne vs kOps: Which Should You Use? kubeone # KubeOne vs kOps: Which Should You Use? ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Mar 17, 2026 11 min read Beginner [comparison](/learn/?tag=comparison) [getting-started](/learn/?tag=getting-started) #### Prerequisites - Basic understanding of Kubernetes architecture - Familiarity with cloud infrastructure concepts (VPCs, instances, load balancers) ## Introduction KubeOne and kOps are both open-source tools for provisioning and managing Kubernetes clusters. They solve similar problems — getting you from zero to a running, production-grade cluster — but they approach the task differently. If you are evaluating which one to adopt, the decision comes down to where your infrastructure lives and how you want to manage it. kOps has been a fixture in the Kubernetes ecosystem since 2016. It is an official Kubernetes SIG project with deep AWS integration and a large community. KubeOne launched later with a different design philosophy: provider-agnostic lifecycle management that works on any infrastructure you can reach over SSH. Both tools are mature, actively maintained, and used in production. This guide gives you a fair comparison so you can choose the right tool for your situation. There is no universal winner here — the right choice depends on your infrastructure, your team’s workflow, and your operational requirements. ## What is KubeOne? KubeOne is an open-source CLI tool by Kubermatic for automated Kubernetes cluster lifecycle management. It handles installation, upgrades, and repair on any SSH-reachable infrastructure — cloud VMs, bare metal servers, or edge devices. KubeOne uses Terraform for infrastructure provisioning and kubeadm for cluster bootstrapping, keeping a clean separation between the two concerns. For a detailed overview, see [What is KubeOne?](/learn/kubeone/what-is-kubeone/). ## What is kOps? kOps (Kubernetes Operations) is an official Kubernetes SIG project for creating, upgrading, and managing production-grade clusters. It has been around since the early days of Kubernetes and has earned its reputation on AWS, where it manages the full stack: VPCs, security groups, auto scaling groups, IAM roles, and Elastic Load Balancers. kOps also supports GCP, DigitalOcean, Hetzner, and OpenStack, though these providers have varying levels of maturity compared to AWS. The tool maintains its own state store — typically an S3 bucket on AWS or a GCS bucket on GCP — to track cluster configuration and detect drift. Where KubeOne delegates infrastructure to Terraform, kOps owns it. You tell kOps what you want, and it creates and manages the cloud resources directly. This is a fundamentally different design philosophy, and it shapes everything about how the two tools behave. ## Head-to-Head Comparison Here is a high-level comparison of the two tools: | Factor | KubeOne | kOps | |---------------------------------|-----------------------------------------|---------------------------------------------| | **Infrastructure Provisioning** | External (Terraform) | Built-in (manages cloud resources directly) | | **Bare Metal Support** | First-class | Not supported | | **AWS Integration** | Via Terraform + CCM | Native (VPC, IAM, ASG, ELB) | | **GCP Integration** | Via Terraform + CCM | Supported (beta) | | **Azure Integration** | Via Terraform + CCM | Supported (alpha) | | **Hetzner/DigitalOcean** | Via Terraform | Supported (alpha/beta) | | **State Management** | Terraform state + cluster state | Own state store (S3/GCS) | | **Cluster Bootstrap** | kubeadm | nodeup/protokube (native) | | **Upgrade Approach** | SSH-based rolling update | Instance group rolling replacement | | **Worker Management** | machine-controller (MachineDeployments) | Instance groups (cloud-native ASGs) | | **CNI Options** | Canal (default), user-configurable | Cilium, Calico, Canal, Flannel, kube-router | | **HA Control Plane** | 3 nodes, any infrastructure | 3+ nodes, cloud-native (ASGs) | | **Edge/IoT** | Supported | Not designed for edge | | **License** | Apache 2.0 | Apache 2.0 | | **Maintained By** | Kubermatic | Kubernetes SIG | The table tells part of the story, but the real differences become clear when you look at how each tool handles specific use cases. ## Deep Dive: Infrastructure Approach ### KubeOne: Terraform + SSH KubeOne deliberately separates infrastructure provisioning from Kubernetes installation. You use Terraform (or any infrastructure-as-code tool) to create your servers, networks, and load balancers. Once the infrastructure exists, KubeOne takes over: it SSHes into the machines, installs the container runtime, bootstraps the control plane with kubeadm, and configures networking and cloud integrations. This separation gives you full control over the infrastructure layer. You can use any cloud provider, any network topology, any instance type. If Terraform can create it, KubeOne can install Kubernetes on it. You can also bring existing infrastructure — servers you provisioned manually, machines in a datacenter, or hardware at a remote site. The trade-off is that you have two tools to learn and manage instead of one. You write Terraform configurations for your infrastructure and a `kubeone.yaml` manifest for your cluster. For teams already using Terraform, this feels natural. For teams that do not use Terraform, it adds a learning curve. ### kOps: Integrated Provisioning kOps manages infrastructure directly. When you run `kops create cluster`, it provisions VPCs, subnets, instances, load balancers, and DNS records on AWS. You describe your desired cluster in a spec, and kOps figures out what cloud resources are needed and creates them. On AWS, this integrated approach is genuinely excellent. kOps understands AWS deeply. It creates auto scaling groups for worker nodes so they scale with demand and automatically replace failed instances. It configures IAM roles with exactly the permissions your cluster needs — no manual policy authoring. It sets up Elastic Load Balancers for the API server and manages their health checks. It handles Route53 DNS records so you get a stable API endpoint. The trade-off is that kOps makes decisions about your infrastructure. It has opinions about how VPCs should be laid out, how subnets should be organized, and how security groups should be configured. If you need a non-standard VPC layout, custom networking, or integration with existing infrastructure that does not match kOps’ expectations, you may find yourself working against the tool rather than with it. > **Tip:** If you already use Terraform to manage your cloud infrastructure, KubeOne fits naturally into your workflow. If you prefer a single tool that handles both infrastructure and Kubernetes — and you are on AWS — kOps is hard to beat. ## Deep Dive: Bare Metal and Edge This is KubeOne’s clearest advantage, and it is not close. kOps does not support bare metal at all. It is designed for cloud infrastructure where it can create and destroy instances programmatically. KubeOne works on any machine you can SSH into. Hetzner dedicated servers, Equinix Metal bare metal, a rack of Dell servers in your datacenter, or a cluster of Raspberry Pis on a shelf. As long as the machine runs a supported Linux distribution and accepts SSH connections, KubeOne can bootstrap Kubernetes on it. For edge computing — factories, retail locations, remote sites, branch offices — KubeOne automates what would otherwise be a manual kubeadm installation. You get the same declarative workflow, the same upgrade process, and the same repair capabilities that you have on cloud VMs. The only difference is that worker node management relies on static workers instead of machine-controller, since there is no cloud API to provision new machines. This matters more than it might seem. Many organizations start on the cloud and later discover they need Kubernetes on-premises or at edge locations. If you chose kOps, you now need a second tool for those environments. If you chose KubeOne, the same tool works everywhere. If bare metal or edge is anywhere in your roadmap, kOps is not an option. ## Deep Dive: The AWS Experience This is kOps’ clearest advantage, and it deserves honest acknowledgment. kOps was built for AWS, and the depth of integration shows in every aspect of the experience. Native auto scaling groups mean your worker nodes scale with demand, replace failed instances automatically, and can use spot instances for significant cost savings. You define instance groups with min and max sizes, and AWS handles the scaling. No additional controllers or operators needed. IAM integration means kOps creates the exact IAM policies your cluster components need. The cloud-controller-manager gets permissions to manage load balancers and routes. The cluster autoscaler gets permissions to modify auto scaling groups. The EBS CSI driver gets permissions to create and attach volumes. You do not write a single IAM policy by hand. ELB management for the API server happens automatically. kOps creates the load balancer, configures health checks, and updates DNS records. When you upgrade the cluster, the load balancer drains connections gracefully. KubeOne on AWS works well — Kubermatic provides Terraform modules for AWS that handle VPCs, subnets, security groups, and instances — but you are configuring these pieces yourself through Terraform. You write the IAM policies, you set up the load balancer, you configure the auto scaling. The result is equivalent, but the effort is higher, and you need to understand both Terraform and AWS networking to get it right. ## Deep Dive: Day-2 Operations The real test of any Kubernetes management tool is not day-1 installation. It is what happens on day 30, day 90, and day 365 — upgrades, repairs, and ongoing maintenance. ### Upgrades With KubeOne, you change the Kubernetes version in your `kubeone.yaml` manifest and run `kubeone apply`. KubeOne SSHes into each control plane node sequentially, performs a kubeadm upgrade, and waits for the node to be healthy before moving to the next one. Worker nodes are upgraded through machine-controller, which performs a rolling replacement: cordon, drain, terminate, create new. The process is the same whether your nodes are on AWS, Hetzner, or bare metal. With kOps, you update the Kubernetes version in the cluster spec, run `kops update cluster` to update the launch configurations, then run `kops rolling-update cluster` to replace instances. kOps terminates old instances in the auto scaling group and lets new instances launch with the updated configuration. Each node is cordoned and drained before termination. Both approaches produce the same result — a safely upgraded cluster with no downtime — but the mechanisms differ. KubeOne’s SSH-based approach performs an in-place upgrade on existing nodes. kOps’ ASG-based approach replaces nodes entirely with fresh instances. The replacement approach is arguably cleaner (no leftover state from the old version), while the in-place approach is faster and works on infrastructure where you cannot create new instances on demand. ### Cluster Repair KubeOne handles repair through convergence. When you run `kubeone apply`, it checks the actual state of the cluster against the desired state and fixes any drift. If a control plane node has failed, KubeOne detects it and re-provisions that specific node without touching the healthy ones. If a certificate has expired, KubeOne rotates it. This works the same on every infrastructure provider. kOps relies on cloud-native self-healing. Auto scaling groups detect failed instances and replace them automatically — no manual intervention needed. This is genuinely hands-off, but it only works on cloud providers where ASGs are available. There is no equivalent mechanism for bare metal. ## When to Choose KubeOne KubeOne is the right choice when: - You need bare metal, edge, or multi-cloud clusters - You already use Terraform for infrastructure management and want Kubernetes to fit into that workflow - You want one tool that works identically across AWS, GCP, Azure, Hetzner, and on-premises hardware - You need clusters on budget-friendly providers like Hetzner or DigitalOcean, or on your own hardware - You want SSH-level control over the cluster bootstrap and upgrade process - Your infrastructure requirements are non-standard and you need full control over VPC layout, networking, and security groups ## When to Choose kOps kOps is the right choice when: - You are AWS-first and want deep, native AWS integration out of the box - You prefer a single tool that handles both infrastructure provisioning and Kubernetes management - You need native auto scaling groups, automatic IAM management, and ELB configuration without writing Terraform - Your entire fleet runs on one cloud provider — specifically AWS - You do not need bare metal or edge support and do not anticipate needing it - You want the backing of an official Kubernetes SIG project with a large community ## Can You Use Both? Yes. There is no rule that says you have to pick one tool for everything. Many organizations have a mix of infrastructure environments, and using the right tool for each environment is a pragmatic approach. You could use kOps for your AWS production clusters where you want that deep integration and automatic scaling, and use KubeOne for your Hetzner development clusters, your on-premises bare metal, or your edge deployments. Both tools produce standard Kubernetes clusters. Your workloads, Helm charts, GitOps pipelines, and monitoring stack work the same regardless of which tool provisioned the cluster. The clusters are just Kubernetes. The provisioning tool is an implementation detail that matters at deployment time but is invisible at runtime. > **Tip:** The “right” tool depends on your infrastructure, not the tool’s feature list. Evaluate based on where your servers are and how you manage them, not on abstract feature comparisons. ## Next Steps Now that you understand the differences, pick a path and try it: - [Installing KubeOne: Your First Cluster in 15 Minutes](/learn/kubeone/installing-kubeone-first-cluster/) — get hands-on with KubeOne - [Provisioning Bare Metal Kubernetes with KubeOne and Terraform](/learn/kubeone/bare-metal-kubernetes-terraform/) — explore KubeOne’s strongest use case - [Deploying KubeOne Clusters on Hetzner Cloud](/learn/kubeone/kubeone-hetzner-cloud/) — a cost-effective cloud alternative to AWS - [kOps Getting Started on AWS](https://kops.sigs.k8s.io/getting_started/aws/) — try kOps where it shines ## Summary KubeOne and kOps are both excellent tools that serve different situations well. kOps is the stronger choice for AWS-heavy organizations that want integrated infrastructure management, native auto scaling, and automatic IAM configuration — all without writing Terraform. KubeOne is the stronger choice for teams that need bare metal support, multi-cloud flexibility, edge deployments, or any infrastructure that kOps does not reach. If your servers are exclusively on AWS and you do not anticipate bare metal or multi-cloud needs, kOps gives you a streamlined, deeply integrated experience. If you need flexibility across providers, operate on bare metal, or already manage your infrastructure with Terraform, KubeOne gives you a consistent workflow that works everywhere. Both tools are open source, both are actively maintained, and both produce standard Kubernetes clusters. You are not making an irreversible decision — and as we discussed, you can always use both. #### Resources - [KubeOne Documentation](https://docs.kubermatic.com/kubeone/) - [kOps Documentation](https://kops.sigs.k8s.io/) - [KubeOne GitHub](https://github.com/kubermatic/kubeone) - [kOps GitHub](https://github.com/kubernetes/kops) #### On This Page - [Introduction](#introduction) - [What is KubeOne?](#what-is-kubeone) - [What is kOps?](#what-is-kops) - [Head-to-Head Comparison](#head-to-head-comparison) - [Deep Dive: Infrastructure Approach](#deep-dive-infrastructure-approach) - [KubeOne: Terraform + SSH](#kubeone-terraform--ssh) - [kOps: Integrated Provisioning](#kops-integrated-provisioning) - [Deep Dive: Bare Metal and Edge](#deep-dive-bare-metal-and-edge) - [Deep Dive: The AWS Experience](#deep-dive-the-aws-experience) - [Deep Dive: Day-2 Operations](#deep-dive-day-2-operations) - [Upgrades](#upgrades) - [Cluster Repair](#cluster-repair) - [When to Choose KubeOne](#when-to-choose-kubeone) - [When to Choose kOps](#when-to-choose-kops) - [Can You Use Both?](#can-you-use-both) - [Next Steps](#next-steps) - [Summary](#summary) --- ## Migrating from Ingress-Nginx to Gateway API with KubeLB - **URL:** https://www.kubermatic.com/learn/kubelb/ingress-nginx-to-gateway-api/ - **Date:** 2026-04-30 [Learn](/learn/) / [Kubelb](/learn/kubelb/) / Migrating from Ingress-Nginx to Gateway API with KubeLB kubelb # Migrating from Ingress-Nginx to Gateway API with KubeLB ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Mar 17, 2026 14 min read Intermediate [gateway-api](/learn/?tag=gateway-api) [load-balancing](/learn/?tag=load-balancing) [networking](/learn/?tag=networking) [migration](/learn/?tag=migration) #### Prerequisites - A Kubernetes cluster with Ingress-Nginx controller deployed - kubectl installed and configured - cert-manager installed (for TLS certificate management) - Basic understanding of Kubernetes Ingress resources ## Introduction The Kubernetes Ingress API served the community well for years, but its limitations are well documented. There is no support for traffic splitting, header-based routing, or TCP/UDP routing. Everything gets crammed into annotations that differ between controllers. If you have ever tried to port an Ingress resource from one controller to another, you know the pain of translating controller-specific annotations that were never designed to be portable. Gateway API is the official successor to Ingress. It is a more expressive, role-oriented API that separates infrastructure concerns (Gateway) from application routing (HTTPRoute). Since reaching GA with v1.0, it has become the standard that the entire Kubernetes networking ecosystem is converging on. On bare metal and self-managed clusters, this migration is harder than on cloud. There is no managed load balancer to handle the transition. You cannot just flip a switch in your cloud provider’s console. KubeLB fills this gap as a Kubernetes-native load balancer designed specifically for bare metal and multi-cluster environments. It provides a Gateway API implementation that works where most others do not. This tutorial walks you through a complete migration from Ingress-Nginx to Gateway API using KubeLB, including TLS certificate migration and a safe cutover strategy. By the end, you will have a production-ready Gateway API setup running alongside your existing Ingress-Nginx controller, with a clear path to decommission it. ## Why Migrate? Before starting the migration, here is why it matters for your infrastructure. **Annotations are a dead end.** Ingress-Nginx relies heavily on annotations for advanced routing. Need URL rewrites? That is `nginx.ingress.kubernetes.io/rewrite-target`. Rate limiting? `nginx.ingress.kubernetes.io/limit-rps`. These annotations are controller-specific and non-portable. When you switch controllers or need to support multiple, you start from scratch. This is not a theoretical concern — it is a daily operational burden for teams managing multiple clusters. **Gateway API is the official Kubernetes standard.** It graduated to GA with v1.0 and is where the ecosystem is moving. Major projects, cloud providers, and service meshes are building Gateway API support. Staying on Ingress means falling behind the ecosystem and missing out on new features that will only ship as Gateway API extensions. **Role-oriented design solves real organizational problems.** Gateway API separates concerns cleanly. Your infrastructure team manages Gateways — the entry points, TLS termination, and listener configuration. Application teams manage HTTPRoutes — the routing rules for their services. This maps naturally to how most organizations already work, but Ingress forced everything into a single resource that both teams had to touch. **KubeLB makes this possible on bare metal.** Most Gateway API implementations are tied to specific cloud providers — AWS Gateway Controller, GKE’s implementation, Azure Application Gateway. KubeLB provides a Gateway API implementation specifically designed for bare metal and multi-cluster setups. If you are running on-premises or in a colocation facility, KubeLB is how you get Gateway API without a cloud provider dependency. ## Step 1: Audit Your Current Ingress Resources Before migrating anything, you need a clear picture of what you have. Surprises during migration come from Ingress resources you forgot about or annotations you did not account for. Start by listing all Ingress resources across every namespace: ```bash # List all Ingress resources across namespaces kubectl get ingress -A ``` Export everything for reference. You will need this backup both as documentation and as a rollback artifact: ```bash # Export each Ingress for reference kubectl get ingress -A -o yaml > ingress-backup.yaml ``` For each Ingress resource, document the following: - Hostname and paths - TLS configuration (certificate secrets) - Backend services and ports - Any annotations (rate limiting, rewrites, auth, etc.) Create a migration checklist that tracks your progress: | Ingress Name | Namespace | Host | Paths | TLS | Annotations | Migrated? | |---------------|-----------|-------------------|---------|-----|----------------------------------|-----------| | app-ingress | default | app.example.com | /, /api | Yes | rewrite-target, ssl-redirect | No | | admin-ingress | admin | admin.example.com | / | Yes | auth-url, whitelist-source-range | No | > **Tip:** Pay special attention to Ingress-Nginx-specific annotations. Some, like `nginx.ingress.kubernetes.io/rewrite-target`, have direct Gateway API equivalents (the URLRewrite filter). Others, like `nginx.ingress.kubernetes.io/auth-url` for external authentication, may require custom solutions or implementation-specific extensions. Identify these early so they do not block your migration later. Take note of how many unique TLS certificates you have and how they are managed. If cert-manager provisions them, the migration is straightforward. If you manually manage certificate secrets, you will need to plan for that separately. ## Step 2: Install Gateway API CRDs Gateway API is not installed by default in most Kubernetes clusters. You need to install the Custom Resource Definitions (CRDs) before you can create any Gateway API resources. Install the standard channel CRDs: ```bash kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.1.0/standard-install.yaml ``` Verify that the CRDs are installed: ```bash kubectl get crd | grep gateway ``` You should see at least three CRDs: - `gateways.gateway.networking.k8s.io` - `httproutes.gateway.networking.k8s.io` - `gatewayclasses.gateway.networking.k8s.io` If you also need TCP or UDP routing (for database connections or game servers, for example), install the experimental channel instead, which includes `TCPRoute` and `UDPRoute` CRDs. For most web application migrations from Ingress-Nginx, the standard channel is sufficient. ## Step 3: Install KubeLB With the Gateway API CRDs in place, install KubeLB as your Gateway API implementation. KubeLB acts as the controller that watches for Gateway and HTTPRoute resources and configures the underlying load balancer infrastructure. Add the KubeLB Helm repository and install the manager: ```bash helm repo add kubelb https://charts.kubelb.io helm repo update helm install kubelb-manager kubelb/kubelb-manager \ --namespace kubelb-system \ --create-namespace \ --set gatewayAPI.enabled=true ``` Verify that KubeLB is running: ```bash kubectl get pods -n kubelb-system ``` All pods should be in `Running` state. KubeLB automatically registers itself as a GatewayClass: ```bash kubectl get gatewayclass ``` You should see a `kubelb` GatewayClass with an `Accepted` status condition. This tells Kubernetes that KubeLB is ready to serve as a Gateway API implementation. > **Warning:** If you set `useLoadBalancerClass: true` in KubeLB’s configuration, make sure it targets only the LoadBalancer services you intend. A misconfiguration here causes KubeLB to manage ALL LoadBalancer services in the cluster, which can conflict with existing services and cause IP exhaustion. Explicitly scope KubeLB to its own LoadBalancerClass to avoid this problem. This is the single most common deployment mistake with KubeLB. ## Step 4: Create Your First Gateway A Gateway is the entry point for traffic. Think of it as the declarative equivalent of the Ingress controller itself — it defines where traffic enters the cluster and how it is terminated. Create a Gateway resource: ```yaml apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: main-gateway namespace: default annotations: cert-manager.io/cluster-issuer: letsencrypt-prod spec: gatewayClassName: kubelb listeners: - name: http protocol: HTTP port: 80 allowedRoutes: namespaces: from: All - name: https protocol: HTTPS port: 443 tls: mode: Terminate certificateRefs: - name: wildcard-tls kind: Secret allowedRoutes: namespaces: from: All ``` There are several important differences from Ingress worth calling out here: - **Listeners are separate from routing rules.** The Gateway defines ports and protocols. The routing rules live in HTTPRoute resources. This separation is the foundation of Gateway API’s role-oriented design. - **TLS termination is configured on the Gateway, not on individual routes.** This makes sense operationally — the infrastructure team controls TLS, and application teams do not need to think about it. - **`allowedRoutes.namespaces.from: All`** lets HTTPRoutes from any namespace attach to this Gateway. In production, you may want to restrict this to specific namespaces using label selectors for tighter access control. Apply the Gateway and wait for it to receive an IP address from KubeLB: ```bash kubectl apply -f gateway.yaml kubectl get gateway main-gateway ``` The `ADDRESS` column in the output should show an IP address once KubeLB has provisioned the load balancer. This is the IP you will eventually point your DNS records to. ## Step 5: Convert Ingress Resources to HTTPRoutes This is the core of the migration. You need to convert each Ingress resource into one or more HTTPRoute resources. Here is a systematic conversion pattern. **Before (Ingress):** ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: app-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: / nginx.ingress.kubernetes.io/ssl-redirect: "true" spec: tls: - hosts: - app.example.com secretName: app-tls rules: - host: app.example.com http: paths: - path: /api pathType: Prefix backend: service: name: api-service port: number: 8080 - path: / pathType: Prefix backend: service: name: frontend-service port: number: 3000 ``` **After (HTTPRoute):** ```yaml apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: app-route spec: parentRefs: - name: main-gateway hostnames: - app.example.com rules: - matches: - path: type: PathPrefix value: /api filters: - type: URLRewrite urlRewrite: path: type: ReplacePrefixMatch replacePrefixMatch: / backendRefs: - name: api-service port: 8080 - matches: - path: type: PathPrefix value: / backendRefs: - name: frontend-service port: 3000 ``` Notice how the HTTPRoute is both more explicit and more structured. There is no ambiguity about what the rewrite does — it is a typed filter, not a regex-laden annotation. The `parentRefs` field explicitly declares which Gateway this route attaches to, making the relationship between infrastructure and routing clear. Here is a reference table for converting common patterns: | Ingress | HTTPRoute | Notes | |-----------------------------|--------------------------|---------------------------------------------------------------| | `spec.rules[].host` | `spec.hostnames[]` | Moved to top-level of the route | | `spec.rules[].http.paths[]` | `spec.rules[].matches[]` | More expressive matching available | | `backend.service` | `backendRefs[]` | Supports multiple backends with weights for traffic splitting | | `rewrite-target` annotation | `URLRewrite` filter | Native, not annotation-based | | `ssl-redirect` annotation | Not needed | Gateway handles TLS termination directly | | TLS secret reference | On the Gateway listener | Not on individual routes | Apply each converted HTTPRoute: ```bash kubectl apply -f app-route.yaml ``` Verify that the route attached successfully: ```bash kubectl get httproute app-route -o yaml ``` Check `status.parents` — it should show your Gateway with an `Accepted` condition set to `True`. ## Step 6: Handle TLS Certificates TLS certificate migration is often the trickiest part of moving from Ingress to Gateway API, especially if you are using Let’s Encrypt with DNS01 challenges. There are two approaches depending on your setup. ### Option A: Reuse Existing Secrets If cert-manager already manages your certificates, the same Kubernetes secrets work with Gateway API. You do not need to re-issue certificates. Reference the existing secret in the Gateway listener: ```yaml listeners: - name: https protocol: HTTPS port: 443 tls: mode: Terminate certificateRefs: - name: existing-tls-secret ``` This is the simplest path. The certificates continue to be renewed by cert-manager through the existing Certificate resources, and the Gateway just reads the same secret. ### Option B: Use cert-manager Gateway API Integration cert-manager natively supports Gateway API. If you want cert-manager to manage certificates based on your Gateway configuration, annotate the Gateway: ```yaml metadata: annotations: cert-manager.io/cluster-issuer: letsencrypt-prod ``` With this annotation, cert-manager watches the Gateway’s listeners and automatically provisions certificates for the hostnames defined in your HTTPRoutes. This is the cleaner long-term approach because it ties certificate lifecycle to the Gateway rather than to legacy Ingress resources. ### DNS01 Challenge Considerations When switching from Ingress to Gateway API, your DNS records change because the new Gateway gets a different IP address from KubeLB. If you use DNS01 challenges for certificate validation, you need external-dns properly synchronized to update DNS records for the new IP. > **Warning:** DNS01 challenges frequently fail during migration if external-dns is not configured to update records for the new Gateway IP. Before cutting over, verify that external-dns has created the correct A/AAAA records for the Gateway’s IP address. Use `dig +short app.example.com` to confirm the IP matches your Gateway’s address. A mismatch here means certificates will not renew, and you will face downtime when current certificates expire. If you use HTTP01 challenges instead, the challenge solver needs to be reachable through the Gateway. Verify that cert-manager’s HTTP01 solver pods are included in your HTTPRoute configuration or can receive traffic through the Gateway. ## Step 7: Run Both in Parallel Do not do a “big bang” cutover. The safest migration strategy runs Ingress-Nginx and Gateway API simultaneously, with DNS controlling which path receives production traffic. Here is the parallel running strategy: 1. **Keep your existing Ingress resources active.** They continue serving production traffic through Ingress-Nginx. Nothing changes for your users yet. 2. **Deploy HTTPRoutes pointing to the same backend services.** Both the Ingress and HTTPRoute resources route to identical backends. The services do not need to change. 3. **Use DNS to control which path receives traffic.** Point a test subdomain to the Gateway IP for validation: ```bash # Point a test subdomain to the Gateway IP for validation # test-app.example.com → Gateway IP (KubeLB) # app.example.com → Ingress-Nginx IP (unchanged) ``` 4. **Test thoroughly through the Gateway endpoint.** Verify all routes, TLS termination, rewrites, and any other behavior you depend on. Run your integration tests against the test subdomain. Check response headers to confirm traffic is flowing through KubeLB and not Ingress-Nginx. 5. **When confident, switch the production DNS to the Gateway IP.** This is the actual cutover moment, and it is controlled entirely through DNS — not Kubernetes resource changes. This approach gives you a clean rollback path at every stage. If something goes wrong after switching DNS, you point it back to the Ingress-Nginx IP. No Kubernetes changes required. ## Step 8: Cutover and Decommission Ingress-Nginx Once all traffic flows through the Gateway and you have validated that everything works correctly, it is time to clean up. Switch your production DNS records to point to the Gateway IP: ```bash # Switch DNS: app.example.com → Gateway IP # Wait for DNS propagation (TTL-dependent, typically 5 minutes to 24 hours) ``` Verify that traffic is flowing through the Gateway: ```bash # Check KubeLB manager logs for incoming traffic kubectl logs -n kubelb-system -l app=kubelb-manager --tail=100 ``` After confirming that production traffic flows correctly through Gateway API, remove the old Ingress resources: ```bash # Remove old Ingress resources kubectl delete ingress app-ingress ``` Wait for a validation period before removing the Ingress-Nginx controller entirely: ```bash # After validation period (1-2 weeks), remove Ingress-Nginx controller helm uninstall ingress-nginx -n ingress-nginx kubectl delete namespace ingress-nginx ``` > **Tip:** Keep Ingress-Nginx installed for 1-2 weeks after cutover as a rollback option. Only decommission it after you are confident that all routes work correctly through Gateway API. The cost of running an idle Ingress-Nginx controller is negligible compared to the cost of not having a rollback path. ## Troubleshooting ### KubeLB Managing Unintended LoadBalancer Services If `useLoadBalancerClass` is misconfigured, KubeLB attempts to manage all LoadBalancer services in the cluster, causing IP conflicts and potential service disruption. **Fix:** Explicitly set the LoadBalancerClass on services you want KubeLB to manage: ```yaml spec: loadBalancerClass: kubelb.io/kubelb ``` This ensures KubeLB only touches services that explicitly opt in. Review all existing LoadBalancer services in the cluster before enabling this feature. ### Envoy xDS Keep-Alive Disconnects **Symptoms:** Routes stop updating after configuration changes. Envoy logs show `Connection is closed by peer during connecting`. **Fix:** Check KubeLB manager pod logs for xDS connection errors. Restart the manager pod if the xDS connection is stale: ```bash kubectl rollout restart deployment kubelb-manager -n kubelb-system ``` For persistent issues, increase the xDS keep-alive interval in KubeLB’s Helm values configuration. This is more common in environments with aggressive network timeouts or firewalls between nodes. ### DNS01 Certificate Validation Failures **Symptoms:** Certificates stuck in `Pending` state. cert-manager logs show DNS01 challenge failures. **Fix:** Verify external-dns is creating TXT records for the ACME challenge: ```bash dig _acme-challenge.app.example.com TXT ``` Check external-dns logs for errors. Common causes include incorrect cloud provider credentials, DNS zone delegation issues, or the external-dns controller not watching Gateway resources (it needs to be configured with the `--source=gateway-httproute` flag). ### HTTPRoute Not Attaching to Gateway **Symptoms:** HTTPRoute shows `status.parents` as empty or with an error condition. **Fix:** Check that the HTTPRoute’s `parentRefs` matches the Gateway name and namespace exactly. Verify the Gateway’s `allowedRoutes` permits routes from the HTTPRoute’s namespace. A common mistake is creating the HTTPRoute in a namespace that the Gateway does not allow: ```bash kubectl get httproute app-route -o jsonpath='{.status.parents}' | jq . ``` If the `conditions` show `NotAllowed`, update the Gateway’s `allowedRoutes` to include the HTTPRoute’s namespace, or move the HTTPRoute to a permitted namespace. ## Common Annotation Migration Reference This table covers the most frequently used Ingress-Nginx annotations and their Gateway API equivalents: | Ingress-Nginx Annotation | Gateway API Equivalent | |--------------------------|-----------------------------------------------| | `rewrite-target` | URLRewrite filter | | `ssl-redirect` | Not needed (Gateway handles TLS) | | `proxy-body-size` | BackendPolicy (implementation-specific) | | `rate-limit-*` | RateLimitPolicy (extension) | | `auth-url` | ExtensionRef filter (implementation-specific) | | `cors-*` | ResponseHeaderModifier filter | | `whitelist-source-range` | Not yet standardized — use NetworkPolicy | | `proxy-connect-timeout` | BackendRef timeout (implementation-specific) | > **Warning:** Not all Ingress-Nginx annotations have direct Gateway API equivalents. Features like external auth (`auth-url`) and advanced rate limiting may require implementation-specific extensions or custom filters. Audit these during Step 1 and plan alternative implementations before starting the migration. Do not discover missing functionality during the cutover. ## Next Steps - [What is KubeLB?](/learn/kubelb/what-is-kubelb/) (coming soon) — understand KubeLB’s architecture and how it manages load balancing across clusters - [KubeLB with KubeOne: Complete Bare Metal Networking Stack](/learn/kubelb/kubelb-kubeone/) (coming soon) — combine KubeLB with KubeOne for a full bare metal networking solution - [Bare Metal Kubernetes with KubeOne and Terraform](/learn/kubeone/bare-metal-kubernetes-terraform/) — set up the cluster that KubeLB load-balances ## Summary You migrated from Ingress-Nginx to Gateway API using KubeLB as the implementation. The key steps were: audit existing Ingress resources, install Gateway API CRDs and KubeLB, create a Gateway with listeners, convert Ingress resources to HTTPRoutes, migrate TLS certificates, run both systems in parallel, and cut over with DNS. The biggest risks in this migration are DNS01 challenge failures during certificate migration and KubeLB’s LoadBalancerClass scope misconfiguration. Both are avoidable with proper preparation during the audit phase. The parallel running strategy is non-negotiable for production environments. Run both systems simultaneously for at least a week before decommissioning Ingress-Nginx. The cost of running an idle controller is nothing compared to the cost of a failed migration with no rollback path. Gateway API gives you a more expressive, portable, and maintainable networking layer. KubeLB makes it work on bare metal where other implementations cannot. Together, they provide a production-grade networking stack that scales with your infrastructure needs. #### Resources - [KubeLB Documentation](https://docs.kubermatic.com/kubelb/) - [Gateway API Documentation](https://gateway-api.sigs.k8s.io/) - [KubeLB GitHub Repository](https://github.com/kubermatic/kubelb) #### On This Page - [Introduction](#introduction) - [Why Migrate?](#why-migrate) - [Step 1: Audit Your Current Ingress Resources](#step-1-audit-your-current-ingress-resources) - [Step 2: Install Gateway API CRDs](#step-2-install-gateway-api-crds) - [Step 3: Install KubeLB](#step-3-install-kubelb) - [Step 4: Create Your First Gateway](#step-4-create-your-first-gateway) - [Step 5: Convert Ingress Resources to HTTPRoutes](#step-5-convert-ingress-resources-to-httproutes) - [Step 6: Handle TLS Certificates](#step-6-handle-tls-certificates) - [Option A: Reuse Existing Secrets](#option-a-reuse-existing-secrets) - [Option B: Use cert-manager Gateway API Integration](#option-b-use-cert-manager-gateway-api-integration) - [DNS01 Challenge Considerations](#dns01-challenge-considerations) - [Step 7: Run Both in Parallel](#step-7-run-both-in-parallel) - [Step 8: Cutover and Decommission Ingress-Nginx](#step-8-cutover-and-decommission-ingress-nginx) - [Troubleshooting](#troubleshooting) - [KubeLB Managing Unintended LoadBalancer Services](#kubelb-managing-unintended-loadbalancer-services) - [Envoy xDS Keep-Alive Disconnects](#envoy-xds-keep-alive-disconnects) - [DNS01 Certificate Validation Failures](#dns01-certificate-validation-failures) - [HTTPRoute Not Attaching to Gateway](#httproute-not-attaching-to-gateway) - [Common Annotation Migration Reference](#common-annotation-migration-reference) - [Next Steps](#next-steps) - [Summary](#summary) --- ## Multi-Cloud Governance with KKP Community Edition and OPA Gatekeeper - **URL:** https://www.kubermatic.com/learn/kkp/multi-cloud-governance/ - **Date:** 2026-04-30 [Learn](/learn/) / [Kkp](/learn/kkp/) / Multi-Cloud Governance with KKP Community Edition and OPA Gatekeeper kkp # Multi-Cloud Governance with KKP Community Edition and OPA Gatekeeper ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Mar 17, 2026 11 min read Intermediate [multi-cloud](/learn/?tag=multi-cloud) [security](/learn/?tag=security) [production](/learn/?tag=production) [platform-engineering](/learn/?tag=platform-engineering) #### Prerequisites - KKP Community Edition installed with a seed cluster - At least one user cluster provisioned through KKP - kubectl configured with access to the seed and user clusters - Basic familiarity with Kubernetes admission controllers ## Introduction Running Kubernetes clusters across multiple cloud providers introduces a governance challenge: how do you ensure every cluster follows the same security and operational policies? Without centralized enforcement, teams end up with inconsistent configurations — one cluster allows privileged containers, another has no resource limits, and a third has namespaces missing required labels. These gaps create security risks and make audits painful. Policy-as-code solves this problem by defining rules that Kubernetes enforces automatically at admission time. OPA Gatekeeper is the standard tool for this in the Kubernetes ecosystem. It uses a webhook-based admission controller that evaluates every API request against your policies before the request is persisted. When combined with Kubermatic Kubernetes Platform (KKP), you can manage policy enforcement across all your clusters from a single control plane. In this tutorial, you will enable OPA Gatekeeper integration on a KKP Community Edition seed cluster, deploy Gatekeeper to a user cluster, and create two policies: one that requires specific labels on namespaces and another that blocks privileged containers. By the end, you will have a working governance setup that you can extend with additional policies for your own requirements. > **Note:** The OPA Gatekeeper integration described here is available in KKP Community Edition. It is configured through the Seed resource, which is fully accessible in KKP CE. No enterprise license is required. **What you will learn:** - How to enable OPA integration on a KKP CE seed cluster - How to write ConstraintTemplates and Constraints for Gatekeeper - How to test policy enforcement and audit existing resources - How to build a library of governance policies for multi-cloud environments * * * ## Prerequisites Before you begin, ensure you have: - **KKP Community Edition** — A running KKP CE installation with at least one seed cluster configured - **A user cluster** — At least one user cluster provisioned through KKP (any cloud provider) - **kubectl** — Version 1.27 or later, configured with access to both the seed cluster and the user cluster - **Cluster admin access** — You need permission to edit Seed resources and create CRDs on the user cluster - **Helm** — Version 3.12 or later (for installing Gatekeeper) **Estimated time:** 25 minutes **Environment used in this tutorial:** - KKP Community Edition: v2.25+ - Kubernetes (user cluster): 1.28+ - OPA Gatekeeper: v3.15+ - Helm: 3.12+ * * * ## Step 1: Verify Your KKP CE Installation and Seed Cluster Before enabling OPA integration, confirm that your KKP CE seed cluster is running and accessible. You will need the name of your seed to update its configuration in the next step. Switch your kubectl context to the seed cluster: ```bash # List available contexts kubectl config get-contexts ``` ```bash # Switch to the seed cluster context kubectl config use-context seed-cluster ``` Verify that the Seed resource exists: ```bash kubectl get seeds -n kubermatic ``` Expected output: ```text NAME AGE europe-west 45d ``` Note the seed name — you will use it in the next step. If you have multiple seeds, you can enable OPA integration on each one independently. > **Tip:** If you do not see any Seed resources, verify that you are connected to the correct cluster. Seed resources exist on the master/seed cluster, not on user clusters. * * * ## Step 2: Enable OPA Integration in the Seed Resource KKP CE provides OPA Gatekeeper integration through the Seed resource configuration. Enabling this tells KKP to support Gatekeeper policy management for all user clusters managed by this seed. Edit the Seed resource to enable OPA integration: ```bash kubectl edit seed europe-west -n kubermatic ``` Add the `opaIntegration` section under `spec`: ```yaml apiVersion: kubermatic.k8c.io/v1 kind: Seed metadata: name: europe-west namespace: kubermatic spec: opaIntegration: enabled: true webhookTimeout: 10 # ... rest of your existing seed configuration ``` The `webhookTimeout` field sets the maximum number of seconds the Gatekeeper admission webhook has to respond before the request is allowed through. A value of 10 seconds provides a reasonable balance between policy evaluation time and user experience. Verify that the Seed resource updated successfully: ```bash kubectl get seed europe-west -n kubermatic -o jsonpath='{.spec.opaIntegration}' | python3 -m json.tool ``` Expected output: ```json { "enabled": true, "webhookTimeout": 10 } ``` * * * ## Step 3: Install Gatekeeper on the User Cluster With OPA integration enabled at the seed level, you now install Gatekeeper on the user cluster where you want to enforce policies. Switch your kubectl context to the target user cluster. ```bash kubectl config use-context user-cluster-01 ``` Add the Gatekeeper Helm repository and install it: ```bash # Add the Gatekeeper Helm repo helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts # Update the repo index helm repo update # Install Gatekeeper into the gatekeeper-system namespace helm install gatekeeper gatekeeper/gatekeeper \ --namespace gatekeeper-system \ --create-namespace \ --set auditInterval=60 \ --set constraintViolationsLimit=50 ``` The `auditInterval` setting tells Gatekeeper to scan existing resources every 60 seconds for policy violations. The `constraintViolationsLimit` controls how many violations are stored per constraint. Wait for the Gatekeeper pods to become ready: ```bash kubectl -n gatekeeper-system wait --for=condition=ready pod -l control-plane=controller-manager --timeout=120s ``` Verify the installation: ```bash kubectl get pods -n gatekeeper-system ``` Expected output: ```text NAME READY STATUS RESTARTS AGE gatekeeper-audit-6b7d4b5f9c-xk2mn 1/1 Running 0 45s gatekeeper-controller-manager-7c9f8d6b4d-2hj7p 1/1 Running 0 45s gatekeeper-controller-manager-7c9f8d6b4d-9xt4k 1/1 Running 0 45s gatekeeper-controller-manager-7c9f8d6b4d-rn3vw 1/1 Running 0 45s ``` You should see one audit pod and three controller-manager pods running. > **Warning:** Do not skip the wait step. If you apply ConstraintTemplates before the Gatekeeper webhook is ready, they may not register correctly. * * * ## Step 4: Create a ConstraintTemplate to Require Namespace Labels Now you will create your first policy. A ConstraintTemplate defines the policy logic using Rego (the OPA policy language), and a Constraint applies that logic to specific resources. This template requires that certain labels exist on namespaces. This is a common governance requirement — teams often need namespaces labeled with an owner, cost center, or environment designation. Create a file called `require-labels-template.yaml`: ```yaml apiVersion: templates.gatekeeper.sh/v1 kind: ConstraintTemplate metadata: name: k8srequiredlabels annotations: description: "Requires specified labels on resources" spec: crd: spec: names: kind: K8sRequiredLabels validation: openAPIV3Schema: type: object properties: labels: type: array description: "List of required label keys" items: type: string targets: - target: admission.k8s.gatekeeper.sh rego: | package k8srequiredlabels violation[{"msg": msg, "details": {"missing_labels": missing}}] { provided := {label | input.review.object.metadata.labels[label]} required := {label | label := input.parameters.labels[_]} missing := required - provided count(missing) > 0 msg := sprintf("Resource is missing required labels: %v", [missing]) } ``` Apply the ConstraintTemplate: ```bash kubectl apply -f require-labels-template.yaml ``` Verify that the template was created and the corresponding CRD is available: ```bash kubectl get constrainttemplates ``` Expected output: ```text NAME AGE k8srequiredlabels 10s ``` ```bash # Confirm the CRD was generated kubectl get crd | grep requiredlabels ``` Expected output: ```text k8srequiredlabels.constraints.gatekeeper.sh 2026-03-17T10:00:00Z ``` > **Tip:** The ConstraintTemplate generates a CRD dynamically. If the CRD does not appear within 30 seconds, check the Gatekeeper controller logs with `kubectl logs -n gatekeeper-system -l control-plane=controller-manager`. * * * ## Step 5: Create a Constraint to Enforce the Template With the template in place, create a Constraint that enforces it. This Constraint will require the `team` and `environment` labels on all namespaces in the cluster. First, create a `production` namespace that you will use for testing: ```bash kubectl create namespace production ``` Now create a file called `require-ns-labels-constraint.yaml`: ```yaml apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sRequiredLabels metadata: name: require-namespace-labels spec: enforcementAction: deny match: kinds: - apiGroups: [""] kinds: ["Namespace"] excludedNamespaces: - kube-system - kube-public - kube-node-lease - default - gatekeeper-system - kubermatic parameters: labels: - "team" - "environment" ``` The `excludedNamespaces` list ensures that system namespaces are not blocked by this policy. Without these exclusions, you could accidentally prevent Kubernetes from creating namespaces it needs to operate. Apply the Constraint: ```bash kubectl apply -f require-ns-labels-constraint.yaml ``` Verify that the Constraint is active: ```bash kubectl get k8srequiredlabels ``` Expected output: ```text NAME ENFORCEMENT-ACTION TOTAL-VIOLATIONS require-namespace-labels deny 1 ``` The `TOTAL-VIOLATIONS` count may already show existing namespaces (like the `production` namespace you just created) that do not have the required labels. * * * ## Step 6: Test Policy Enforcement Now test that the policy is working. Try to create a namespace without the required labels. Gatekeeper should reject it. ```bash kubectl create namespace test-no-labels ``` Expected output: ```text Error from server (Forbidden): admission webhook "validation.gatekeeper.sh" denied the request: [require-namespace-labels] Resource is missing required labels: {"environment", "team"} ``` The request was denied because the namespace is missing the `team` and `environment` labels. Now create a namespace with the required labels: ```bash cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Namespace metadata: name: test-with-labels labels: team: "platform" environment: "staging" EOF ``` Expected output: ```text namespace/test-with-labels created ``` The namespace was created successfully because it includes both required labels. Fix the `production` namespace that was created earlier without labels: ```bash kubectl label namespace production team=backend environment=production ``` Verify the violation count has decreased: ```bash kubectl get k8srequiredlabels require-namespace-labels -o jsonpath='{.status.totalViolations}' ``` Expected output: ```text 0 ``` Clean up the test namespace: ```bash kubectl delete namespace test-with-labels ``` * * * ## Step 7: Add a Second Policy to Block Privileged Containers A single policy is a good start, but real governance requires multiple layers. Add a second policy that prevents containers from running in privileged mode. Privileged containers have full access to the host, which is a significant security risk in any multi-tenant or production environment. Create the ConstraintTemplate in a file called `block-privileged-template.yaml`: ```yaml apiVersion: templates.gatekeeper.sh/v1 kind: ConstraintTemplate metadata: name: k8sblockprivilegedcontainer annotations: description: "Blocks containers from running in privileged mode" spec: crd: spec: names: kind: K8sBlockPrivilegedContainer targets: - target: admission.k8s.gatekeeper.sh rego: | package k8sblockprivilegedcontainer violation[{"msg": msg}] { container := input.review.object.spec.containers[_] container.securityContext.privileged == true msg := sprintf("Container <%v> is not allowed to run as privileged", [container.name]) } violation[{"msg": msg}] { container := input.review.object.spec.initContainers[_] container.securityContext.privileged == true msg := sprintf("Init container <%v> is not allowed to run as privileged", [container.name]) } ``` This template checks both regular containers and init containers. Apply it: ```bash kubectl apply -f block-privileged-template.yaml ``` Now create the Constraint in a file called `block-privileged-constraint.yaml`: ```yaml apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sBlockPrivilegedContainer metadata: name: block-privileged-containers spec: enforcementAction: deny match: kinds: - apiGroups: [""] kinds: ["Pod"] namespaces: - production excludedNamespaces: - kube-system ``` This Constraint targets pods in the `production` namespace specifically. Apply it: ```bash kubectl apply -f block-privileged-constraint.yaml ``` Test by attempting to create a privileged pod: ```bash cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: privileged-test namespace: production spec: containers: - name: nginx image: nginx:latest securityContext: privileged: true EOF ``` Expected output: ```text Error from server (Forbidden): error when creating "STDIN": admission webhook "validation.gatekeeper.sh" denied the request: [block-privileged-containers] Container <nginx> is not allowed to run as privileged ``` Now try a non-privileged pod to confirm legitimate workloads still deploy: ```bash cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: safe-test namespace: production spec: containers: - name: nginx image: nginx:latest securityContext: privileged: false EOF ``` Expected output: ```text pod/safe-test created ``` Clean up the test pod: ```bash kubectl delete pod safe-test -n production ``` * * * ## Step 8: Audit Existing Resources for Policy Violations Gatekeeper does not only enforce policies on new resources — it also audits existing resources on a regular interval (configured by `auditInterval` during installation). This is valuable for understanding your current compliance posture across the cluster. Check for violations across all constraints: ```bash kubectl get k8srequiredlabels require-namespace-labels -o yaml | grep -A 50 'violations:' ``` You can also list all constraints and their violation counts in a single command: ```bash kubectl get constraints ``` Expected output: ```text NAME ENFORCEMENT-ACTION TOTAL-VIOLATIONS block-privileged-containers deny 0 require-namespace-labels deny 0 ``` For a detailed view of which resources are violating a specific constraint: ```bash kubectl describe k8srequiredlabels require-namespace-labels ``` Look for the `Status.Violations` section in the output. Each entry lists the violating resource, its namespace, and the specific policy message. > **Tip:** To get a cluster-wide compliance report, you can set `enforcementAction: warn` instead of `deny` on new constraints. This logs violations without blocking requests, which is useful during a rollout period where you want to assess impact before enforcing. To switch an existing constraint to warn-only mode for auditing purposes: ```bash kubectl patch k8srequiredlabels require-namespace-labels \ --type='merge' \ -p '{"spec":{"enforcementAction":"warn"}}' ``` Remember to set it back to `deny` once you have addressed the violations: ```bash kubectl patch k8srequiredlabels require-namespace-labels \ --type='merge' \ -p '{"spec":{"enforcementAction":"deny"}}' ``` * * * ## Troubleshooting ### Gatekeeper webhook is not intercepting requests **Cause:** The webhook configuration may not be registered, or Gatekeeper pods are not ready. **Solution:** ```bash # Check that the webhook exists kubectl get validatingwebhookconfigurations | grep gatekeeper # Verify pods are running kubectl get pods -n gatekeeper-system # Check controller logs for errors kubectl logs -n gatekeeper-system -l control-plane=controller-manager --tail=50 ``` ### ConstraintTemplate CRD is not created **Cause:** The Rego code in the template may have syntax errors, preventing the CRD from being generated. **Solution:** ```bash # Check the ConstraintTemplate status for errors kubectl get constrainttemplate k8srequiredlabels -o jsonpath='{.status}' # Look for error events kubectl describe constrainttemplate k8srequiredlabels ``` Review the Rego code for typos or incorrect package names. The package name in the Rego block must match the ConstraintTemplate name (lowercased). ### Constraint shows violations but does not block requests **Cause:** The `enforcementAction` may be set to `warn` or `dryrun` instead of `deny`. **Solution:** ```bash # Check the enforcement action kubectl get k8srequiredlabels require-namespace-labels -o jsonpath='{.spec.enforcementAction}' ``` If the output is `warn` or `dryrun`, update it to `deny`: ```bash kubectl patch k8srequiredlabels require-namespace-labels \ --type='merge' \ -p '{"spec":{"enforcementAction":"deny"}}' ``` ### Audit violations are not updating **Cause:** The audit controller runs on a schedule defined by `auditInterval`. There may also be resource limits preventing the audit pod from completing its scan. **Solution:** ```bash # Check the audit pod logs kubectl logs -n gatekeeper-system -l control-plane=audit-controller --tail=50 # Restart the audit pod to trigger an immediate scan kubectl delete pod -n gatekeeper-system -l control-plane=audit-controller ``` * * * ## Next Steps Now that you have a working governance setup, consider these directions: - [**Gatekeeper Policy Library**](https://open-policy-agent.github.io/gatekeeper-library/) — Browse pre-built policies for common requirements like image registries, ingress restrictions, and resource quotas - [**KKP User Cluster Management**](/learn/kkp/) — Learn more about managing user clusters across multiple clouds with KKP - **Expand your policy library** — Add policies for container image allowlists, ingress hostname restrictions, and required annotations for cost tracking - **Integrate with CI/CD** — Use `gator test` (the Gatekeeper CLI) to validate policies in your pipeline before they reach the cluster * * * ## Summary You enabled OPA Gatekeeper integration on a KKP Community Edition seed cluster and installed Gatekeeper on a user cluster. You created two policies: one requiring `team` and `environment` labels on namespaces, and another blocking privileged containers in the production namespace. You tested enforcement by verifying that non-compliant resources are rejected while compliant ones are accepted, and you used Gatekeeper’s audit capability to check existing resources against your policies. This same pattern extends to any number of clusters managed by KKP — define your policies once and deploy them across your entire multi-cloud fleet. #### Resources - [OPA Gatekeeper Documentation](https://open-policy-agent.github.io/gatekeeper/) - [KKP OPA Integration Guide](https://docs.kubermatic.com/kubermatic/) - [Gatekeeper Policy Library](https://open-policy-agent.github.io/gatekeeper-library/) #### On This Page - [Introduction](#introduction) - [Prerequisites](#prerequisites) - [Step 1: Verify Your KKP CE Installation and Seed Cluster](#step-1-verify-your-kkp-ce-installation-and-seed-cluster) - [Step 2: Enable OPA Integration in the Seed Resource](#step-2-enable-opa-integration-in-the-seed-resource) - [Step 3: Install Gatekeeper on the User Cluster](#step-3-install-gatekeeper-on-the-user-cluster) - [Step 4: Create a ConstraintTemplate to Require Namespace Labels](#step-4-create-a-constrainttemplate-to-require-namespace-labels) - [Step 5: Create a Constraint to Enforce the Template](#step-5-create-a-constraint-to-enforce-the-template) - [Step 6: Test Policy Enforcement](#step-6-test-policy-enforcement) - [Step 7: Add a Second Policy to Block Privileged Containers](#step-7-add-a-second-policy-to-block-privileged-containers) - [Step 8: Audit Existing Resources for Policy Violations](#step-8-audit-existing-resources-for-policy-violations) - [Troubleshooting](#troubleshooting) - [Gatekeeper webhook is not intercepting requests](#gatekeeper-webhook-is-not-intercepting-requests) - [ConstraintTemplate CRD is not created](#constrainttemplate-crd-is-not-created) - [Constraint shows violations but does not block requests](#constraint-shows-violations-but-does-not-block-requests) - [Audit violations are not updating](#audit-violations-are-not-updating) - [Next Steps](#next-steps) - [Summary](#summary) --- ## Planning Your VMware to KubeVirt Migration - **URL:** https://www.kubermatic.com/learn/kubevirt/vmware-to-kubevirt-migration-planning/ - **Date:** 2026-04-30 [Learn](/learn/) / [Kubevirt](/learn/kubevirt/) / Planning Your VMware to KubeVirt Migration kubevirt # Planning Your VMware to KubeVirt Migration ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Mar 17, 2026 14 min read Intermediate [migration](/learn/?tag=migration) [virtualization](/learn/?tag=virtualization) #### Prerequisites - Understanding of VMware vSphere concepts (ESXi, vCenter, datastores, vSwitch) - Basic Kubernetes knowledge (pods, PVs, StorageClasses, CNI) - Familiarity with KubeVirt — see [What is KubeVirt?](/learn/kubevirt/what-is-kubevirt/) Broadcom’s acquisition of VMware changed the economics of enterprise virtualization overnight. License costs doubled or tripled for many organizations, and the perpetual license model that teams relied on for budget predictability is gone. If you are reading this, you are probably feeling that pressure right now. KubeVirt is emerging as the primary open-source alternative. It lets you run virtual machines on Kubernetes with no license fees, using commodity hardware and the same orchestration layer you already use for containers. The project is mature, backed by Red Hat and the CNCF (currently an Incubating project), and used in production by organizations across industries. But migration is not as simple as “lift and shift.” VMware and Kubernetes have fundamentally different architectures, different networking models, different storage paradigms, and different operational workflows. Rushing into migration without a plan is the fastest path to a failed project and a frustrated team. This guide walks you through the planning phase: assessing your VMware estate, mapping concepts between platforms, choosing a migration path, designing your target architecture, and building a phased runbook that reduces risk at every step. By the end, you will have a clear plan that you can take to your team and your leadership. This is the planning guide. The hands-on conversion tutorial, where you will use virt-v2v to convert VMware VMs to KubeVirt, is covered in Part 2 of this series. ## Step 1: Assess Your Current VMware Estate Before migrating anything, you need a clear inventory. This sounds obvious, but most organizations underestimate how much institutional knowledge is locked inside their vCenter. VMs accumulate over years, and documentation drifts. Start by documenting every VM you plan to migrate. For each VM, capture the following: | Field | What to Capture | Why It Matters | |--------------|--------------------------------|-------------------------------------------------------------------------| | OS Type | Windows/Linux, version | KubeVirt supports both, but Windows needs specific drivers (virtio-win) | | Disk Format | VMDK thin/thick, size | Determines conversion method and storage requirements | | CPU/Memory | vCPU count, RAM | Maps directly to KubeVirt resource requests | | Network | vSwitch/NSX, VLANs, static IPs | Networking is the hardest part of the migration | | Storage | Datastore type, IOPS needs | Drives StorageClass selection on the Kubernetes side | | Dependencies | Other VMs, external services | Determines migration order | | GPU | Passthrough devices | Requires IOMMU configuration on Kubernetes nodes | Use vCenter’s export functionality or tools like RVTools to generate this inventory automatically. RVTools is particularly useful because it exports to spreadsheets, which makes it easy to sort, filter, and share with your team. While you are building this inventory, identify VMs that are candidates for containerization instead of migration. If a workload is already stateless, runs a single application process, and has no dependency on the underlying OS, it probably should not be a VM at all. Those workloads should skip the VM step entirely and move straight to containers. Your migration project is a good opportunity to make that call. ## Step 2: Map VMware Concepts to KubeVirt This is the mental model shift that your team needs to internalize before touching any tooling. VMware and KubeVirt solve the same problem — running virtual machines — but they use completely different abstractions. If your team tries to operate KubeVirt like they operate vCenter, they will struggle. Here is the mapping: | VMware Concept | KubeVirt Equivalent | Notes | |--------------------------|-----------------------------|------------------------------------------------------| | ESXi Host | Kubernetes Node | Nodes run KVM via the virt-handler DaemonSet | | vCenter | Kubernetes API Server | All management through kubectl or the API | | Virtual Machine | VirtualMachine CR | Persistent definition that survives restarts | | VM Instance (running) | VirtualMachineInstance | Ephemeral runtime object, similar to a Pod | | Datastore | StorageClass + PV | Ceph, Longhorn, local-path, or cloud volumes | | VMDK | DataVolume (QCOW2) | CDI handles import and format conversion | | vSwitch | CNI (Calico, Cilium) | Pod networking provides default connectivity | | Port Group / NSX Segment | NetworkAttachmentDefinition | Multus required for Layer 2 or multiple NICs | | vMotion | Live Migration | KubeVirt supports live migration with shared storage | | Snapshot | VolumeSnapshot | CSI driver must support snapshots | | Template | VM with DataVolumeTemplate | Clone from a golden image | | Resource Pool | Namespace + ResourceQuota | Kubernetes-native resource management | The most important shift is operational. In VMware, you manage infrastructure through a GUI (vCenter) with point-and-click workflows. In KubeVirt, everything is a YAML manifest applied through kubectl or virtctl. Your infrastructure becomes code, which is a significant advantage for automation and reproducibility, but it requires a different skill set. Spend time with your team reviewing this mapping. Make sure everyone understands where their familiar VMware concepts land in the Kubernetes world before you start migrating workloads. ## Step 3: Choose Your Migration Path There are three approaches, and most organizations end up using a mix of all three. ### Path A: Forklift (Migration Toolkit for Virtualization) Forklift is an open-source tool (part of the Konveyor community project, and the upstream of Red Hat’s Migration Toolkit for Virtualization) that automates bulk VM migration from VMware to KubeVirt. It connects directly to your vCenter, discovers VMs, converts disk images, and imports them into your Kubernetes cluster. This is the right choice for large estates with 50 or more VMs, where manual conversion would take too long. Forklift handles the repetitive work: disk conversion, network mapping, and VM creation. It also provides a web UI for tracking migration progress, which is useful for reporting to stakeholders. The trade-off is that Forklift is another tool to install, configure, and manage. It requires vCenter API access, and you need to understand its mapping model (how it translates VMware networks and storage to Kubernetes resources). For small environments, the setup overhead may not be worth it. ### Path B: Manual Conversion with virt-v2v Use libguestfs virt-v2v to convert VMDK files to QCOW2 format, then import them into KubeVirt via the Containerized Data Importer (CDI). This gives you full control over every step of the process, with no additional tooling beyond virt-v2v and kubectl. This path is best for smaller estates, air-gapped environments where you cannot install Forklift, or teams that want to understand every detail of the conversion process. It is also the right choice for VMs that need special handling — custom drivers, unusual disk layouts, or non-standard configurations. The trade-off is more manual work per VM. Each conversion requires running virt-v2v, uploading the resulting image, creating the DataVolume, and writing the VirtualMachine manifest. Part 2 of this series walks through this process step by step. ### Path C: Rebuild (Re-platform) Instead of migrating the VM, containerize the application or rebuild it on Kubernetes-native services. If a workload is already stateless, runs a standard application stack (Node.js, Python, Java), and does not depend on specific OS-level configuration, it is a better candidate for containerization than VM migration. This is the highest effort per workload, but it results in the best long-term architecture. Containers are lighter, faster to deploy, and easier to scale than VMs. If you are going through the effort of leaving VMware, consider whether some workloads should leapfrog VMs entirely. > **Tip:** Most organizations use a mix of all three paths. Containerize what you can (Path C), bulk-migrate standard VMs with Forklift (Path A), and manually convert the tricky ones with virt-v2v (Path B). Categorize each VM in your inventory by the path that makes the most sense. ``` flowchart TD Start[VM from VMware inventory] Q1{Stateless app + standard stack?} Q2{50+ similar VMs to migrate?} Q3{Special drivers or unusual config?} Start --> Q1 Q1 -->|Yes| Rebuild["Path C: Rebuild as container (highest long-term value)"] Q1 -->|No| Q2 Q2 -->|Yes| Forklift["Path A: Forklift (automated bulk migration)"] Q2 -->|No| Q3 Q3 -->|Yes| V2V["Path B: virt-v2v manual (full control per VM)"] Q3 -->|No| V2V ``` ## Step 4: Design Your Target Architecture With your inventory complete and migration paths assigned, you need to design the Kubernetes cluster that will host your VMs. Three areas require the most attention: compute, storage, and networking. ### Compute Sizing Each KubeVirt VM runs inside a virt-launcher pod. The pod requests the same CPU and memory as the VM, so your Kubernetes nodes need enough capacity to host the VMs you are migrating, plus overhead. Plan for the same total capacity as your VMware estate, plus 15-20% overhead for Kubernetes system components (kubelet, kube-proxy, CoreDNS) and the KubeVirt stack itself (virt-controller, virt-handler, virt-api). If you are running a storage solution like Ceph on the same nodes, add another 10-15% for storage daemons. For GPU workloads, nodes need IOMMU enabled in the BIOS and kernel. Add `intel_iommu=on` or `amd_iommu=on` to your GRUB configuration, depending on your processor vendor. GPU passthrough in KubeVirt works well, but it requires upfront configuration that you do not want to discover you need on migration day. ### Storage Backend This is the most critical decision in your target architecture. Your storage choice determines whether you can use live migration, how your backups work, and what performance your VMs will get. - **Ceph (via Rook)**: Distributed storage that supports RWX access mode, which is required for live migration. Production-grade and battle-tested, but higher operational complexity. If you are migrating a large VMware estate and need live migration, Ceph is the standard choice. - **Longhorn**: Simpler distributed storage, well-suited for mid-size deployments. Longhorn’s KubeVirt support is growing, and it is easier to operate than Ceph for smaller teams. - **Local storage (hostpath-provisioner)**: Best raw performance because there is no network overhead. However, VMs using local storage are pinned to the node where their data lives. No live migration support — node maintenance requires VM shutdown. - **Cloud volumes (EBS, Persistent Disk)**: Works if you are running Kubernetes on a cloud provider. Be aware of single-AZ constraints for block volumes and the IOPS limits of standard volume types. > **Warning:** Live migration requires shared storage with RWX (ReadWriteMany) access mode. If you choose local storage, VMs cannot be migrated between nodes. Node maintenance, kernel upgrades, and hardware failures all require VM shutdown and restart. Make this trade-off consciously. ### Networking Default pod networking through Calico or Cilium works for most VMs. Each VM gets a pod IP address and can communicate with other pods, services, and external endpoints through standard Kubernetes networking. The complications start when your VMs need Layer 2 network access. Many legacy applications expect to see broadcast traffic, use ARP for discovery, or require specific VLANs. Standard Kubernetes CNIs operate at Layer 3 (IP routing), which means these Layer 2 expectations break. For VMs that need Layer 2 access, install Multus CNI and create NetworkAttachmentDefinitions with bridge or macvtap plugins. Multus allows you to attach multiple network interfaces to a single pod (or VM), so a VM can have one interface on the pod network and another on a bridged Layer 2 segment. | Requirement | CNI Recommendation | |---------------------------|----------------------------| | Basic pod networking only | Calico or Cilium | | Layer 2 access needed | Multus + bridge or macvtap | | Multiple NICs per VM | Multus (mandatory) | | Network policies | Calico or Cilium | ## Step 5: Plan Your Network Migration Networking deserves its own section because it is where most VMware-to-KubeVirt migrations fail. Storage is a close second, but networking failures are more subtle and harder to debug. ### IP Address Management VMs in KubeVirt get pod IPs by default, which are assigned by the CNI and change if the VM is rescheduled to a different node. If your VMs have hardcoded IP addresses, static DNS entries, or application configurations that reference specific IPs, you have two options: - Use Multus with a bridge plugin and a DHCP server on the same Layer 2 segment, so VMs get predictable IPs from your existing DHCP infrastructure. - Assign static IPs via cloud-init or the QEMU guest agent during VM creation. Neither option is as smooth as VMware’s networking model, where a VM keeps its IP regardless of which host it runs on. Plan for this friction and allocate time for testing. ### NSX to Kubernetes Mapping If you are running NSX-T or NSX-V, each segment or port group needs a corresponding NetworkAttachmentDefinition in Kubernetes. Document every segment, which VMs use it, and what Layer 2 or Layer 3 properties it provides. This mapping exercise is tedious but essential — missing a network segment during migration means a VM comes up without connectivity to a critical dependency. ### DNS Updates Update DNS records to point to the new KubeVirt VM IP addresses. Plan for a dual-run period where both VMware and KubeVirt versions of a VM are running, and use DNS or load balancer changes to shift traffic. Do not cut over DNS and decommission the VMware VM in the same maintenance window. > **Warning:** Layer 2 and Layer 3 friction is the number one technical issue in KubeVirt networking. Standard Kubernetes CNIs operate at Layer 3 (IP routing), but many legacy VMs expect Layer 2 behavior (ARP, broadcast, DHCP). If your VMs need Layer 2, you must use Multus with a bridge or macvtap plugin. Test this configuration early in your migration, not during production cutover. ## Step 6: Build Your Migration Runbook A phased approach reduces risk. Do not try to migrate everything at once. ### Phase 1: Dev/Test VMs (Week 1-2) Start with non-critical development and test VMs. These are your learning environment. Migrate them, validate that networking works, check storage performance, and confirm that applications behave correctly. Use this phase to build team confidence with the tooling and to discover issues in a low-stakes environment. Document every issue you encounter and how you resolved it. This documentation becomes your playbook for the production phases. ### Phase 2: Stateless Production VMs (Week 3-4) Migrate production VMs that are stateless or easily replaceable: web servers, API gateways, reverse proxies, and similar workloads. Run them in parallel with the VMware versions for one to two weeks, shifting traffic gradually through DNS changes or load balancer updates. This phase validates that KubeVirt can handle production traffic and that your monitoring, alerting, and incident response workflows work with the new platform. ### Phase 3: Stateful Production VMs (Week 5-8) Databases, file servers, and VMs with persistent state are the hardest to migrate. They require careful data migration, validation of data integrity, and planned maintenance windows for the final cutover. For databases, consider using replication to keep the VMware and KubeVirt instances in sync during the transition. Cut over by promoting the KubeVirt replica and updating connection strings. This minimizes downtime and gives you a fast rollback path. ### Phase 4: Decommission VMware (Week 9+) Once all workloads are validated on KubeVirt, decommission your ESXi hosts and vCenter. Reallocate the hardware to Kubernetes nodes if it meets your requirements, or retire it. Cancel or downgrade your VMware licenses. Do not rush this phase. Keep VMware running until you are confident that every migrated workload is stable. The cost of running both platforms for an extra week or two is far less than the cost of a failed migration with no rollback. ## Risk Mitigation Four strategies will protect you during migration: **Rollback strategy.** Keep VMware running during the entire migration period. For each VM, maintain the ability to revert to the VMware version until the KubeVirt version has been validated in production for at least one full business cycle (typically one to two weeks). **Performance baseline.** Benchmark key VMs on VMware before migration. Capture CPU utilization, memory usage, disk IOPS, and network throughput. After migration, run the same benchmarks on KubeVirt and compare. If performance drops significantly, investigate before migrating the next batch. **Dual-run period.** Budget for running both platforms simultaneously for two to four weeks. This costs more in infrastructure but eliminates the risk of a “big bang” migration where everything moves at once and there is no fallback. **Skills gap.** Your team knows VMware. They know vCenter, ESXi, vMotion, and the VMware ecosystem. KubeVirt uses different tools: kubectl, virtctl, Kubernetes RBAC, and YAML manifests. Plan training time before the migration starts, not during it. The KubeVirt user guide and the other tutorials in this series are a good starting point. ## Next Steps With your plan in place, you are ready to start the hands-on work: - **Converting VMware VMs to KubeVirt: A Step-by-Step Guide with virt-v2v** (coming soon) — Part 2 of this series covers the actual conversion process - [Troubleshooting KubeVirt: CNI Conflicts, CDI Errors, and Common Fixes](/learn/kubevirt/troubleshooting-kubevirt/) — for the issues you will hit during migration - [Installing KubeVirt on a Kubernetes Cluster](/learn/kubevirt/installing-kubevirt/) — set up your target environment before you start migrating ## Summary Migrating from VMware to KubeVirt is a significant infrastructure project, but it is entirely achievable with the right plan. Start by inventorying your VMware estate and documenting every VM’s configuration, dependencies, and network requirements. Map VMware concepts to their KubeVirt equivalents so your team understands the new platform. Choose migration paths — Forklift for bulk migration, virt-v2v for manual control, and containerization where it makes sense. Design your target architecture with particular attention to storage (shared storage is required for live migration) and networking (Layer 2 friction is the most common failure point). Execute in phases, starting with dev/test and working up to stateful production workloads. Keep VMware running as a rollback option until you are confident in the new platform. The planning phase is the foundation. Get it right, and the execution becomes methodical. Skip it, and you will spend more time firefighting than migrating. #### Resources - [KubeVirt User Guide](https://kubevirt.io/user-guide/) - [virt-v2v Documentation](https://libguestfs.org/virt-v2v.1.html) - [Migration Toolkit for Virtualization (Forklift)](https://github.com/kubev2v/forklift) #### On This Page - [Step 1: Assess Your Current VMware Estate](#step-1-assess-your-current-vmware-estate) - [Step 2: Map VMware Concepts to KubeVirt](#step-2-map-vmware-concepts-to-kubevirt) - [Step 3: Choose Your Migration Path](#step-3-choose-your-migration-path) - [Path A: Forklift (Migration Toolkit for Virtualization)](#path-a-forklift-migration-toolkit-for-virtualization) - [Path B: Manual Conversion with virt-v2v](#path-b-manual-conversion-with-virt-v2v) - [Path C: Rebuild (Re-platform)](#path-c-rebuild-re-platform) - [Step 4: Design Your Target Architecture](#step-4-design-your-target-architecture) - [Compute Sizing](#compute-sizing) - [Storage Backend](#storage-backend) - [Networking](#networking) - [Step 5: Plan Your Network Migration](#step-5-plan-your-network-migration) - [IP Address Management](#ip-address-management) - [NSX to Kubernetes Mapping](#nsx-to-kubernetes-mapping) - [DNS Updates](#dns-updates) - [Step 6: Build Your Migration Runbook](#step-6-build-your-migration-runbook) - [Phase 1: Dev/Test VMs (Week 1-2)](#phase-1-devtest-vms-week-1-2) - [Phase 2: Stateless Production VMs (Week 3-4)](#phase-2-stateless-production-vms-week-3-4) - [Phase 3: Stateful Production VMs (Week 5-8)](#phase-3-stateful-production-vms-week-5-8) - [Phase 4: Decommission VMware (Week 9+)](#phase-4-decommission-vmware-week-9) - [Risk Mitigation](#risk-mitigation) - [Next Steps](#next-steps) - [Summary](#summary) --- ## Troubleshooting KubeVirt: CNI Conflicts, CDI Errors, and Common Fixes - **URL:** https://www.kubermatic.com/learn/kubevirt/troubleshooting-kubevirt/ - **Date:** 2026-04-30 [Learn](/learn/) / [Kubevirt](/learn/kubevirt/) / Troubleshooting KubeVirt: CNI Conflicts, CDI Errors, and Common Fixes kubevirt # Troubleshooting KubeVirt: CNI Conflicts, CDI Errors, and Common Fixes ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Mar 17, 2026 12 min read Intermediate [troubleshooting](/learn/?tag=troubleshooting) [virtualization](/learn/?tag=virtualization) [networking](/learn/?tag=networking) #### Prerequisites - A running KubeVirt installation — see [Installing KubeVirt](/learn/kubevirt/installing-kubevirt/) - kubectl and virtctl installed - Basic familiarity with KubeVirt concepts — see [What is KubeVirt?](/learn/kubevirt/what-is-kubevirt/) KubeVirt adds a virtualization layer on top of Kubernetes, which means debugging spans two stacks: the Kubernetes layer (pods, services, PVs) and the KVM/libvirt layer (QEMU processes, virtio drivers, disk images). When something breaks, you need to know which stack to look at first and how to trace the problem from one layer into the other. This guide covers the five most frequently reported issues in KubeVirt deployments, drawn from GitHub issues, community forums, and production experience. Each issue follows the same structure: symptoms you will see, how to diagnose, the root cause, and how to fix it. Before you start, make sure you have these tools ready: `kubectl`, `virtctl`, and SSH access to your cluster nodes for node-level debugging. You will need all three at various points in this guide. ## Issue 1: CNI Conflicts — VMs Cannot Reach the Network This is the single most common problem teams hit when deploying KubeVirt for the first time. It comes down to a fundamental mismatch between what Kubernetes networking provides and what virtual machines expect. ### Symptoms - The VM boots successfully but cannot ping external hosts. - The VM can ping the node IP but not other pods or the internet. - ARP requests from the VM are not being resolved. ### Diagnosis Start by checking the VMI status and network configuration: ```bash # Check the VMI status and network info kubectl get vmi <vm-name> -o yaml | grep -A 20 interfaces ``` Next, inspect the network namespace inside the virt-launcher pod: ```bash # Check the virt-launcher pod's network namespace kubectl exec -it virt-launcher-<vm-name>-xxxxx -- ip addr ``` If the interfaces look correct, check whether traffic is actually reaching the VM’s virtual bridge: ```bash # Check if traffic reaches the VM's virtual bridge kubectl exec -it virt-launcher-<vm-name>-xxxxx -- tcpdump -i k6t-eth0 -n ``` If you see ARP requests leaving the VM but no replies coming back, you have a Layer 2/Layer 3 conflict. ### Root Cause Standard Kubernetes CNIs (Calico, Cilium, Flannel) operate at Layer 3 — they route IP packets between pods. But many VMs expect Layer 2 connectivity: ARP resolution, broadcast traffic, and direct Ethernet framing. The virtual ethernet bridge (`k6t-eth0`) inside the virt-launcher pod bridges the VM’s NIC to the pod network, but Layer 2 frames do not traverse the CNI’s overlay correctly. The CNI only knows how to forward IP packets, not raw Ethernet frames, so ARP requests from the VM disappear into a void. ### Fix You have two options depending on your requirements. **For basic connectivity (VM just needs internet and pod-to-pod access):** Use the default `masquerade` binding mode. This NATs VM traffic through the pod IP, which works with any CNI because the VM’s traffic exits the pod as regular IP packets: ```yaml spec: domain: devices: interfaces: - name: default masquerade: {} networks: - name: default pod: {} ``` Masquerade mode handles the translation between the VM’s internal network and the pod network transparently. The VM gets an internal IP (typically 10.0.2.15), and all outbound traffic is NATed through the pod’s IP address. **For Layer 2 access (VM needs DHCP, broadcast, or VLANs):** Install Multus CNI and create a NetworkAttachmentDefinition with a bridge plugin: ```yaml apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: name: br-lan spec: config: | { "cniVersion": "0.3.1", "type": "bridge", "bridge": "br-lan", "ipam": {} } ``` Then attach your VM to this network: ```yaml spec: domain: devices: interfaces: - name: lan bridge: {} networks: - name: lan multus: networkName: br-lan ``` > **Warning:** Layer 2/Layer 3 friction is the number one networking issue in KubeVirt. If your VMs need Layer 2 (which most legacy VMs do), you must use Multus. There is no workaround within the default pod network. Plan for this early in your deployment rather than retrofitting it later. ## Issue 2: CDI Importer Errors — DataVolumes Stuck The Containerized Data Importer (CDI) handles importing disk images into PVCs. When it fails, your VMs cannot start because there is no disk to boot from. ### Symptoms - DataVolume stuck in `ImportScheduled` or `ImportInProgress` for an extended period. - CDI importer pod shows errors or restarts repeatedly. - `kubectl get dv <name>` shows progress stuck at 0% or a low percentage. ### Diagnosis ```bash # Check DataVolume status kubectl describe dv <datavolume-name> # Find and check the importer pod kubectl get pods -l cdi.kubevirt.io/storage.import.importPvcName=<pvc-name> kubectl logs <cdi-importer-pod-name> ``` The importer pod logs are where the real answers live. The DataVolume status will tell you it is stuck; the pod logs will tell you why. ### Common Causes and Fixes **Cause A: PVC size too small.** The target PVC must be at least as large as the disk image’s virtual size. QCOW2 images have a virtual size that can be much larger than their file size on disk — a 2GB QCOW2 file might expand to a 50GB virtual disk. ```bash # Check virtual size of a QCOW2 image qemu-img info <image-file> ``` Look for the “virtual size” field. Set your DataVolume’s PVC size to at least this value, plus some headroom for filesystem overhead (roughly 5-10% extra). **Cause B: StorageClass does not support dynamic provisioning.** CDI needs to create scratch PVCs during the import process for format conversion and validation. If the default StorageClass does not support dynamic provisioning, the scratch PVC stays in a Pending state and the import never progresses. Fix: Set a default StorageClass that supports dynamic provisioning, or specify `spec.storage.storageClassName` explicitly in your DataVolume manifest. Verify with `kubectl get sc` — the default class should have `(default)` next to its name and a provisioner that supports dynamic provisioning. **Cause C: Unsupported source format.** CDI supports QCOW2, RAW, VMDK (with conversion), and ISO out of the box. Other formats like VHD or VHDX require manual conversion before import. ```bash qemu-img convert -f vhd -O qcow2 source.vhd target.qcow2 ``` **Cause D: Network issues pulling the image.** If the DataVolume source is an HTTP URL, the importer pod needs outbound network access. Check for proxy configuration, DNS resolution failures, or firewall rules blocking egress from the cluster. The importer pod runs in the same namespace as your DataVolume, so namespace-level NetworkPolicies can also block it. > **Tip:** For large images (50GB+), imports can take 30+ minutes even on fast networks. Check the CDI importer pod logs for progress updates before assuming the process is stuck. The logs report percentage completion and throughput — if those numbers are moving, the import is working. ## Issue 3: VM Fails to Start — virt-launcher CrashLoopBackOff When a VM fails to start, the symptom almost always surfaces as a failing virt-launcher pod. This pod is the wrapper process that manages the QEMU instance for your VM, so any issue with the VM configuration, node capabilities, or resource availability shows up here. ### Symptoms - VirtualMachineInstance stuck in `Scheduling` or `Failed`. - virt-launcher pod in CrashLoopBackOff. - Events show errors related to device access or resource limits. ### Diagnosis ```bash # Check VMI events kubectl describe vmi <vm-name> # Check virt-launcher pod logs kubectl logs virt-launcher-<vm-name>-xxxxx # On the node, check libvirt logs (requires SSH) journalctl -u kubelet | grep <vm-name> ``` The VMI events will usually contain the first clue. The virt-launcher logs contain the detailed error from QEMU or libvirt. ### Common Causes and Fixes **Cause A: KVM device not available.** You will see errors like `device /dev/kvm not found` or `failed to create domain`. This means the node does not have hardware virtualization enabled, or the `/dev/kvm` device is not accessible to the pod. Fix: SSH into the node and check that `/dev/kvm` exists. If it does not, enable VT-x (Intel) or AMD-V (AMD) in the BIOS/UEFI settings. If you are running on cloud instances, you need instances that support nested virtualization (not all instance types do). As a last resort for development environments, you can enable software emulation in the KubeVirt CR by setting `useEmulation: true`, but never use this in production — it is orders of magnitude slower. **Cause B: Insufficient resources.** Errors like `insufficient memory` or `CPU pinning failed` mean the VM is requesting more CPU or memory than is available on any schedulable node. Fix: Check node allocatable resources: ```bash kubectl describe node <node-name> | grep -A 10 "Allocatable" ``` Compare against your VM’s resource requests. Remember that Kubernetes system components, DaemonSets, and other pods consume resources too. Either reduce the VM’s resource requests or add capacity to the cluster. **Cause C: Image pull failure.** If you are using a `containerDisk` source, the virt-launcher pod must pull the container image that contains the disk. Image pull errors — wrong registry URL, missing authentication, or the image tag does not exist — cause CrashLoopBackOff with image-related error messages in the pod events. Fix: Verify the image URL is correct, check that `imagePullSecrets` are configured in the VM’s namespace, and test pulling the image manually: ```bash crictl pull <image-url> ``` ## Issue 4: Live Migration Failures Live migration is one of the key advantages of running VMs on KubeVirt — it lets you move running VMs between nodes for maintenance, load balancing, or upgrades. But it has strict prerequisites that are not always obvious. ### Symptoms - Migration stuck in `Scheduling` or `TargetReady` phase. - Migration fails with timeout or eviction errors. - `kubectl get vmim` shows failed migrations. ### Diagnosis ```bash # Check migration status kubectl get vmim -A kubectl describe vmim <migration-name> # Check target node's virt-handler logs kubectl logs -n kubevirt virt-handler-xxxxx --since=5m ``` The migration object’s events will tell you which phase failed. The virt-handler logs on the target node show what went wrong during the actual migration attempt. ### Prerequisites for Live Migration Before troubleshooting the specific error, verify these three prerequisites are met: 1. **Shared storage.** The VM’s PVCs must use a ReadWriteMany (RWX) access mode. Both the source and target nodes need simultaneous access to the same storage. Local storage, hostPath volumes, and ReadWriteOnce PVCs do not work. 2. **Compatible CPU models.** The source and target nodes must have compatible CPU feature sets. If the source node has AVX-512 and the target does not, migration will fail. Use `spec.domain.cpu.model: host-model` for flexibility across heterogeneous clusters, or pin to a specific baseline model. 3. **Sufficient network bandwidth.** Large VMs with active workloads generate dirty pages faster than migration can copy them. If the dirty page rate exceeds the migration bandwidth, the migration never converges and eventually times out. ### Common Fixes Switch storage to a distributed backend that supports RWX access — Rook-Ceph, Longhorn, or your cloud provider’s shared filesystem. This is non-negotiable for live migration. If network bandwidth is a constraint, set an explicit migration bandwidth limit to prevent migration traffic from saturating the network: ```yaml apiVersion: kubevirt.io/v1 kind: KubeVirt metadata: name: kubevirt namespace: kubevirt spec: configuration: migrations: bandwidthPerMigration: 64Mi ``` You can also increase the migration timeout and set the number of allowed convergence steps to give large VMs more time to complete: ```yaml spec: configuration: migrations: completionTimeoutPerGiB: 800 progressTimeout: 150 ``` > **Warning:** Without shared storage (RWX), live migration is impossible. VMs on local storage are pinned to their node. Plan your storage backend accordingly before you need to evacuate nodes for maintenance. ## Issue 5: Poor VM Performance Your VM starts and runs, but it feels noticeably slower than a bare-metal or traditional hypervisor setup. This is not an inherent limitation of KubeVirt — it is almost always a configuration issue. ### Symptoms - The VM feels sluggish despite adequate resource allocation. - CPU-intensive workloads run significantly slower than expected. - Disk I/O benchmarks show numbers far below host-level benchmarks. ### Diagnosis First, check whether software emulation is active: ```bash # Check if using software emulation kubectl get kubevirt kubevirt -n kubevirt -o jsonpath='{.spec.configuration.developerConfiguration.useEmulation}' ``` If that returns `true`, you have found your problem. Next, check the CPU model the VM is actually using: ```bash virtctl console <vm-name> # Inside the VM, run: lscpu | grep "Model name" ``` If the model name shows something generic like “QEMU Virtual CPU” instead of your actual host CPU, you are not getting CPU passthrough. ### Common Causes and Fixes **Cause A: Software emulation.** If `useEmulation: true`, the VM runs entirely on QEMU without KVM hardware acceleration. This is 10-100x slower than hardware-accelerated virtualization. It exists only for development and testing on machines without VT-x/AMD-V. Fix: Enable hardware virtualization on your nodes and set `useEmulation: false` (or remove the setting entirely, since `false` is the default). **Cause B: No CPU passthrough.** By default, KubeVirt presents a generic CPU model to VMs. This ensures broad compatibility but hides performance-enhancing CPU features from the guest. For CPU-intensive workloads, pass through the host CPU features: ```yaml spec: domain: cpu: model: host-passthrough dedicatedCpuPlacement: true ``` The `dedicatedCpuPlacement` option pins VM vCPUs to physical cores, eliminating scheduling jitter. Note that this requires the CPU manager to be enabled on the node (kubelet `--cpu-manager-policy=static`). **Cause C: No hugepages.** For memory-intensive VMs, the default 4KB page size causes translation lookaside buffer (TLB) pressure and frequent page table walks. Hugepages (2MB or 1GB) reduce this overhead significantly: ```yaml spec: domain: memory: hugepages: pageSize: 2Mi resources: requests: memory: 4Gi ``` The node must have hugepages pre-allocated. On each node: ```bash echo 2048 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages ``` For persistent configuration, add `hugepagesz=2M hugepages=2048` to the kernel boot parameters. **Cause D: Virtio drivers missing.** This primarily affects Windows VMs. Without virtio drivers, KubeVirt falls back to IDE emulation for disks and e1000 emulation for network — both are dramatically slower than their virtio counterparts. Disk throughput can drop by 5-10x without virtio. Fix: Install the virtio-win drivers inside the VM guest. You can attach the virtio-win ISO as a secondary CD-ROM during VM creation and install the drivers from within Windows Device Manager. ## Diagnostic Commands Reference Keep this table handy when troubleshooting. These are the commands you will reach for most often: | Command | Purpose | |-----------------------------------------------------------|------------------------------------| | `kubectl get vmi` | List running VM instances | | `kubectl describe vmi <name>` | Detailed VMI status and events | | `virtctl console <name>` | Access VM serial console | | `virtctl ssh <name>` | SSH into VM (requires guest agent) | | `kubectl logs virt-launcher-<name>-xxx` | virt-launcher pod logs | | `kubectl get dv` | DataVolume import status | | `kubectl get vmim` | Migration status | | `kubectl -n kubevirt logs -l kubevirt.io=virt-handler` | virt-handler logs | | `kubectl -n kubevirt logs -l kubevirt.io=virt-controller` | virt-controller logs | ## Next Steps - [What is KubeVirt?](/learn/kubevirt/what-is-kubevirt/) — review the fundamentals if any of the concepts in this guide were unfamiliar - [Installing KubeVirt](/learn/kubevirt/installing-kubevirt/) — verify your installation is configured correctly - [Planning Your VMware to KubeVirt Migration](/learn/kubevirt/vmware-to-kubevirt-migration-planning/) — migration planning guide for teams moving off VMware ## Summary The most common KubeVirt issues fall into five categories: networking (Layer 2/Layer 3 CNI friction), disk image import (CDI sizing and format issues), VM startup failures (KVM device, resources, image pulls), live migration (storage and CPU compatibility), and performance (emulation, CPU model, hugepages). For networking, use masquerade mode for simple setups and Multus with a bridge plugin for Layer 2 requirements. For performance, ensure hardware virtualization is enabled and consider CPU passthrough and hugepages for demanding workloads. When in doubt, start with the virt-launcher pod logs — they contain the most useful error messages in the KubeVirt stack. #### Resources - [KubeVirt User Guide - Troubleshooting](https://kubevirt.io/user-guide/operations/debug/) - [KubeVirt GitHub Issues](https://github.com/kubevirt/kubevirt/issues) - [CDI Documentation](https://github.com/kubevirt/containerized-data-importer) #### On This Page - [Issue 1: CNI Conflicts — VMs Cannot Reach the Network](#issue-1-cni-conflicts--vms-cannot-reach-the-network) - [Symptoms](#symptoms) - [Diagnosis](#diagnosis) - [Root Cause](#root-cause) - [Fix](#fix) - [Issue 2: CDI Importer Errors — DataVolumes Stuck](#issue-2-cdi-importer-errors--datavolumes-stuck) - [Symptoms](#symptoms-1) - [Diagnosis](#diagnosis-1) - [Common Causes and Fixes](#common-causes-and-fixes) - [Issue 3: VM Fails to Start — virt-launcher CrashLoopBackOff](#issue-3-vm-fails-to-start--virt-launcher-crashloopbackoff) - [Symptoms](#symptoms-2) - [Diagnosis](#diagnosis-2) - [Common Causes and Fixes](#common-causes-and-fixes-1) - [Issue 4: Live Migration Failures](#issue-4-live-migration-failures) - [Symptoms](#symptoms-3) - [Diagnosis](#diagnosis-3) - [Prerequisites for Live Migration](#prerequisites-for-live-migration) - [Common Fixes](#common-fixes) - [Issue 5: Poor VM Performance](#issue-5-poor-vm-performance) - [Symptoms](#symptoms-4) - [Diagnosis](#diagnosis-4) - [Common Causes and Fixes](#common-causes-and-fixes-2) - [Diagnostic Commands Reference](#diagnostic-commands-reference) - [Next Steps](#next-steps) - [Summary](#summary) --- ## What is kcp? Kubernetes Without the Pods - **URL:** https://www.kubermatic.com/learn/kcp/what-is-kcp/ - **Date:** 2026-04-30 [Learn](/learn/) / [Kcp](/learn/kcp/) / What is kcp? Kubernetes Without the Pods kcp # What is kcp? Kubernetes Without the Pods ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Mar 17, 2026 9 min read Beginner [getting-started](/learn/?tag=getting-started) [platform-engineering](/learn/?tag=platform-engineering) [multi-tenancy](/learn/?tag=multi-tenancy) #### Prerequisites - Basic understanding of Kubernetes concepts (API server, CRDs, RBAC) - Familiarity with the concept of multi-tenancy ## Introduction Platform engineering is how most organizations solve the “every team needs their own Kubernetes” problem. The standard playbook is straightforward: spin up a cluster per team, layer on some RBAC, wire up a GitOps pipeline, and call it a day. It works, but it is expensive. Each cluster carries the overhead of a control plane, a set of nodes, monitoring, upgrades, and the operational burden of keeping it all running. kcp takes a fundamentally different approach. What if you could give every team what *looks* like their own Kubernetes cluster — with its own CRDs, its own RBAC, its own resources — but without running any compute? Just the API machinery. That is exactly what kcp does. It is a CNCF Sandbox project that provides Kubernetes-like API machinery — the control plane — without pods, nodes, or container orchestration. You get the parts of Kubernetes that manage state and APIs, without the parts that manage compute. ## What is kcp? kcp is an open-source, horizontally scalable control plane for Kubernetes-like APIs. It was [accepted to the CNCF Sandbox on September 19, 2023](https://www.cncf.io/projects/kcp/), with the first commit dating back to July 2020. At its core, kcp provides **workspaces** — each one acts like an independent Kubernetes API server. You can create CRDs, apply RBAC policies, run admission webhooks, and manage resources within each workspace. From the outside, interacting with a workspace feels exactly like interacting with a Kubernetes cluster. You use `kubectl`. You write standard YAML manifests. Your existing tools work without modification. The critical difference: there are no pods. No nodes. No container runtime. No scheduler deciding where to place workloads. kcp is the Kubernetes API machinery stripped down to its essence — CRDs, RBAC, admission control, and resource management — without the scheduling and compute layer. As the project itself puts it: kcp “does not replace Kubernetes, but complements it as a backend to host Kubernetes-like APIs as SaaS.” Because a workspace is backed by a logical cluster stored in its own etcd prefix range, workspaces are cheap. A single kcp instance can host many thousands of them — each with its own CRDs, its own RBAC, its own object storage — rather than spinning up a full Kubernetes control plane per tenant. ## How is kcp Different from Kubernetes? The easiest way to understand kcp is to look at what it keeps and what it drops from Kubernetes: | Kubernetes Has | kcp Has | kcp Does NOT Have | |-------------------|--------------------------------------------|-------------------------------| | API Server | API Server | Pods | | CRDs | CRDs | Nodes / kubelet | | RBAC | RBAC | Kube-scheduler | | Admission Control | Admission Control | Kube-controller-manager | | Namespaces | Workspaces (stronger isolation) | Container runtime | | etcd | etcd (logical clusters, disjoint prefixes) | Built-in workload controllers | The key insight here: kcp takes only the parts of Kubernetes that manage state and APIs, and drops the parts that manage compute. This is not a limitation — it is a design decision. The control plane and the compute plane are separate concerns, and kcp lets you treat them that way. kcp on its own does not run containers and does not schedule workloads onto physical Kubernetes clusters. Earlier versions of kcp shipped a *Syncer* and Transparent Multi-Cluster (TMC) code for that purpose, but [both were removed from the project in May 2023](https://github.com/kcp-dev/kcp) to refocus kcp on pure API management. When workloads are needed, API providers run their own multi-tenant operators that read from kcp workspaces (via APIBindings) and reconcile into real Kubernetes clusters or any other backend. kcp is the control plane; compute stays where it already lives. ## Key Concepts Three concepts form the foundation of kcp. Understanding these gives you the mental model for everything else. ### Workspaces Workspaces are the fundamental isolation unit in kcp. Each workspace is [a Kubernetes-cluster-like HTTPS endpoint](https://docs.kcp.io/kcp/main/concepts/workspaces/) backed by its own logical cluster in etcd, with disjoint storage prefixes. That means a workspace has its own CRDs, its own RBAC, and its own object storage — no sharing with other workspaces. If namespaces in Kubernetes are rooms in a shared house, workspaces in kcp are separate houses entirely. Workspaces are hierarchical. A workspace can contain child workspaces, which can contain their own children, arranged in a tree. Workspace *types* govern which parents can hold which children, so the hierarchy maps naturally to organizational structures: a top-level workspace for your platform team, child workspaces for each product team, and grandchild workspaces for individual environments like staging and production. > **Tip:** From a developer’s perspective, interacting with a workspace is identical to interacting with a Kubernetes cluster. Point `kubectl`, `client-go`, or `helm` at the workspace endpoint and everything works. ### APIExport An `APIExport` is how a provider workspace publishes APIs that other workspaces can consume. It references one or more `APIResourceSchemas` — the CRD-like schemas that define the shape of the exported APIs — and exposes them for binding. Think of it as a service catalog entry. A database team creates an `APIExport` to say: “I offer a `Database` resource. Here is its schema. Here is how to reach the controller that reconciles it.” ### APIBinding An `APIBinding` is how a consumer workspace imports and uses a published API. It references an `APIExport` and binds every API defined there into the consuming workspace. Once bound, the consumer can `kubectl apply` a `Database` manifest as if the CRD were installed locally — but the controller reconciling it lives in the provider’s workspace, not the consumer’s. Together, `APIExport` and `APIBinding` create a decentralized service catalog. Providers publish what they offer. Consumers bind to what they need. The platform team governs which exports are visible to which workspaces through workspace hierarchy and RBAC. No tickets. No manual provisioning. Just APIs. ``` flowchart LR subgraph Provider["Provider Workspace (db-team)"] Schema[APIResourceSchema databases.v1.example.io] Export[APIExport database-service] Controller[Multi-tenant operator] Schema --> Export end subgraph Consumer["Consumer Workspace (app-team)"] Binding[APIBinding → database-service] DB[Database my-app-prod] Binding --> DB end Export -. published .-> Binding Controller -. reconciles .-> DB DB -. provisions .-> Backend[(Real DB on k8s / cloud)] ``` ### Running workloads with kcp kcp itself does not run containers. To put APIs bound in a workspace to work, a provider typically runs a **multi-tenant operator** that watches across the workspaces that bind its `APIExport` and reconciles into whatever backend it cares about — one or many physical Kubernetes clusters, a cloud provider, or a bespoke system. The kcp community calls this pattern “APIs as a service”: kcp is the control plane, someone else’s operator is the compute. ## When Should You Use kcp? kcp is not a general-purpose replacement for Kubernetes. It solves specific problems well. Here are three concrete use cases where kcp shines. ### Internal Developer Platforms Give every team a workspace that looks and feels like a Kubernetes cluster. Developers interact with standard `kubectl` commands, write standard manifests, and use the tools they already know. But behind the scenes, you are running a single kcp instance instead of dozens of separate clusters. The cost savings are significant. You eliminate the control plane overhead of individual clusters, reduce the operational burden of managing upgrades and patches across many clusters, and centralize policy enforcement. ### SaaS Control Planes If you are building a multi-tenant SaaS product, kcp gives you a natural isolation model. Each customer gets their own workspace with custom APIs tailored to their needs. Workspaces provide strong isolation guarantees — one customer cannot see or affect another’s resources. This pattern works especially well for infrastructure products: managed databases, CI/CD platforms, monitoring services, or anything where customers need their own resource namespace with API-driven management. ### API-First Platform Engineering Use APIExport and APIBinding to build a self-service platform where service teams publish what they offer and consumer teams bind to what they need. This creates a decentralized, API-driven service catalog that scales with your organization. Instead of a central platform team bottleneck fielding requests, each team advertises its capabilities as APIs. Consumers discover and bind to them. The platform team governs access through RBAC and workspace hierarchy, without being in the critical path for every request. ## kcp vs Traditional Multi-Tenancy Multi-tenancy in Kubernetes has been a persistent challenge. Here is how the main approaches compare: - **Namespaces**: Weak isolation within a shared cluster. All tenants share the same CRDs, the same API server, and the same control plane. Fine for trusted teams within a single organization, but the boundaries are soft. - **vcluster**: Virtual Kubernetes clusters that run as workloads inside a host cluster — each vcluster gets its own API server (typically k3s or k8s) and its own data store. Stronger isolation than namespaces, and workloads run for real. But every vcluster still consumes compute on the host, and you are still responsible for the host cluster. - **kcp Workspaces**: Full API-level isolation with zero compute overhead. Each workspace is an independent API scope. No shared CRDs, no shared resources, no shared control plane state. Best suited for platform building where you need strong isolation at scale. Each approach fits different situations. Namespaces work for simple cases. vcluster works when you need virtual cluster semantics with existing compute. kcp works when you need the API isolation without the compute cost. For a deeper comparison, see [kcp Workspaces vs Namespaces vs vcluster](/learn/kcp/workspaces-vs-namespaces-vs-vcluster/). ## The Bigger Picture kcp is the foundation of the Kubermatic Developer Platform (KDP). It provides the multi-tenant, API-driven control plane that KDP builds on to deliver a full developer platform experience. This fits a broader trend in the platform engineering movement. The industry is shifting toward API-driven, self-service infrastructure where platform teams build products for their internal developers. kcp represents a specific architectural pattern within that shift: the control plane as a product, not a side effect of running containers. By separating the control plane from compute, kcp lets you scale your platform’s API layer independently of your compute layer. You can serve thousands of tenants from a single kcp instance and attach compute clusters only where and when you need them. > **Warning:** kcp is a CNCF Sandbox project. It is under active development and not yet recommended for production workloads without careful evaluation. The API surface may change between releases. ## Next Steps Ready to get hands-on? The next tutorial in this series walks you through installing kcp and creating your first workspace: - [Installing kcp and Creating Your First Workspace](/learn/kcp/installing-kcp-first-workspace/) If you are evaluating multi-tenancy options and want a more detailed comparison of the approaches mentioned above, check out the dedicated comparison guide: - [kcp Workspaces vs Namespaces vs vcluster](/learn/kcp/workspaces-vs-namespaces-vs-vcluster/) ## Summary kcp is Kubernetes without the compute layer — pure API machinery for building multi-tenant platforms. It provides workspaces for isolation and `APIExport`/`APIBinding` for a decentralized service catalog. Compute stays with whoever runs the operators behind the APIs. If you are building an Internal Developer Platform or a multi-tenant SaaS product, kcp gives you Kubernetes-compatible isolation at a fraction of the cost of running separate clusters. #### Resources - [kcp Documentation](https://docs.kcp.io/) - [kcp GitHub Repository](https://github.com/kcp-dev/kcp) - [CNCF kcp Project Page](https://www.cncf.io/projects/kcp/) #### On This Page - [Introduction](#introduction) - [What is kcp?](#what-is-kcp) - [How is kcp Different from Kubernetes?](#how-is-kcp-different-from-kubernetes) - [Key Concepts](#key-concepts) - [Workspaces](#workspaces) - [APIExport](#apiexport) - [APIBinding](#apibinding) - [Running workloads with kcp](#running-workloads-with-kcp) - [When Should You Use kcp?](#when-should-you-use-kcp) - [Internal Developer Platforms](#internal-developer-platforms) - [SaaS Control Planes](#saas-control-planes) - [API-First Platform Engineering](#api-first-platform-engineering) - [kcp vs Traditional Multi-Tenancy](#kcp-vs-traditional-multi-tenancy) - [The Bigger Picture](#the-bigger-picture) - [Next Steps](#next-steps) - [Summary](#summary) --- ## What is KubeOne? Automated Kubernetes Lifecycle Management - **URL:** https://www.kubermatic.com/learn/kubeone/what-is-kubeone/ - **Date:** 2026-04-30 [Learn](/learn/) / [Kubeone](/learn/kubeone/) / What is KubeOne? Automated Kubernetes Lifecycle Management kubeone # What is KubeOne? Automated Kubernetes Lifecycle Management ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Mar 17, 2026 8 min read Beginner [getting-started](/learn/?tag=getting-started) [automation](/learn/?tag=automation) #### Prerequisites - Basic understanding of Kubernetes architecture (control plane, worker nodes) - Familiarity with SSH and basic Linux administration ## Introduction Setting up a Kubernetes cluster is not the hard part anymore. Tools like kubeadm, managed services, and one-click installers have made day-1 straightforward. The hard part is everything after that: upgrading Kubernetes versions without downtime, replacing failed nodes at 2 AM, rotating certificates before they expire, patching CVEs across your control plane and workers. That is where most teams burn time — and where most tools leave you on your own. KubeOne is Kubermatic’s open-source tool that automates the full lifecycle of Kubernetes clusters: installation, upgrades, and repair. It works on any infrastructure where you can reach servers over SSH — AWS, GCP, Azure, Hetzner, bare metal, edge locations, or the server rack in your basement. You describe your desired cluster state in a YAML file, and KubeOne makes it happen. KubeOne is licensed under Apache 2.0 and fully open source. No enterprise paywall for core functionality. ## What is KubeOne? KubeOne is a CLI tool that manages the complete lifecycle of Kubernetes clusters. You run `kubeone apply`, and it handles installation, configuration, upgrades, and repairs — all from a single declarative manifest. Built by Kubermatic, the company behind the Kubermatic Kubernetes Platform (KKP), KubeOne was designed to solve a specific problem: automating Kubernetes operations on infrastructure that managed services do not reach. If you have SSH access to a server, KubeOne can turn it into a Kubernetes node. Under the hood, KubeOne uses kubeadm — the official Kubernetes bootstrapping tool. What KubeOne adds on top is automation, declarative configuration, Terraform integration, and day-2 operations. Instead of running a dozen kubeadm commands manually and hoping you got the flags right, you define your cluster in YAML and let KubeOne execute the correct sequence every time. KubeOne handles both day-1 and day-2 operations: - **Day-1**: Provision the container runtime, bootstrap the control plane with kubeadm, set up etcd, deploy networking and cloud integrations, create worker nodes. - **Day-2**: Detect version drift, perform rolling upgrades of control plane and worker nodes, repair broken nodes, manage addons, rotate certificates. ## How KubeOne Works KubeOne’s architecture is straightforward. Four components work together to take you from bare servers to a running cluster. ### KubeOneCluster Manifest Everything starts with a YAML file called the KubeOneCluster manifest. This file declares your desired cluster state: the Kubernetes version you want, which cloud provider you are targeting, control plane host addresses, networking configuration, and any addons you want deployed. This file is your single source of truth. Version control it, review it in pull requests, and apply it with confidence. ### Terraform Integration KubeOne does not provision infrastructure. That is Terraform’s job, and KubeOne stays out of its way. Instead, KubeOne reads Terraform output to discover your infrastructure — server IPs, SSH keys, load balancer addresses, cloud-specific metadata. You run `terraform apply` to create servers, then `terraform output -json` feeds that information to KubeOne. Kubermatic maintains official Terraform examples for every supported cloud provider in the [KubeOne GitHub repository](https://github.com/kubermatic/kubeone). These are production-tested configurations you can use directly or adapt to your needs. > **Tip:** You can skip Terraform entirely and specify hosts manually in the KubeOneCluster manifest. This is common for bare metal setups where servers already exist and you just need KubeOne to install Kubernetes on them. ### SSH-Based Execution KubeOne connects to your servers over SSH, installs the container runtime (containerd), bootstraps kubeadm, and configures the cluster. There is no agent to install, no daemon to maintain, no control plane running on your laptop. KubeOne runs, does its work over SSH, and exits. The next time you run it, it connects again, compares actual state to desired state, and makes any necessary changes. ### machine-controller Once the control plane is up, KubeOne deploys [machine-controller](https://github.com/kubermatic/machine-controller) — a Kubernetes-native controller that manages worker nodes declaratively. You define MachineDeployment resources (similar to Deployments, but for machines), and machine-controller provisions and joins worker nodes automatically. Need to scale from 3 to 10 workers? Update the replica count. Need to rotate all workers to a new OS image? Update the spec and machine-controller rolls them out. ### The Full Flow ``` flowchart LR TF[Terraform provisions servers] Manifest["KubeOneCluster manifest (YAML)"] K1["kubeone apply (your laptop / CI)"] TF -->|terraform output| K1 Manifest --> K1 K1 -->|SSH| CP["Control-plane nodes (kubeadm init/join)"] CP --> Cluster[(Running cluster)] Cluster --> MC[machine-controller] MC -->|manages| Workers[Worker nodes via MachineDeployment] ``` ## Key Features **Multi-provider support.** AWS, GCP, Azure, Hetzner Cloud, DigitalOcean, OpenStack, Equinix Metal, VMware vSphere, Nutanix, and bare metal. If you can SSH into it, KubeOne can manage it. **Automated upgrades.** Run `kubeone apply` with a new Kubernetes version in your manifest. KubeOne detects the version drift and performs a rolling upgrade — control plane nodes first, then workers. No manual draining, no manual kubeadm upgrade commands, no crossing your fingers. **HA control planes.** Three control plane nodes with etcd distributed across them, configured out of the box. KubeOne handles the etcd bootstrapping and join process that is notoriously tricky to do by hand. **Addon system.** Deploy CNI plugins (Canal, Cilium), CSI drivers, cloud controller managers, and your own custom addons as part of the cluster lifecycle. Addons are applied on every `kubeone apply` run, so drift is corrected automatically. **Declarative configuration.** One YAML file describes your entire cluster. No imperative commands to remember, no sequence of steps to get right. Declare what you want, apply it, and KubeOne figures out how to get there. **Encrypted secrets.** KubeOne integrates with credential providers so your cloud API keys and SSH keys are never stored in plaintext in your manifest. ## When Should You Use KubeOne? ### Bare Metal and Budget Clouds You have servers — maybe Hetzner, maybe Equinix Metal, maybe physical machines in a datacenter. You need Kubernetes but managed services like EKS or GKE are not an option (wrong provider, too expensive, or simply not available for your infrastructure). KubeOne gives you a production-grade, HA Kubernetes cluster on any hardware, with automated upgrades included. ### Edge and IoT You need Kubernetes running at remote locations — factory floors, retail stores, cell towers, oil rigs. These environments typically have limited connectivity and no cloud API to call. KubeOne automates what would otherwise be manual SSH-and-pray operations: install Kubernetes, upgrade it months later when a maintenance window opens, repair it when a node fails. ### Multi-Cloud Consistency Your organization runs workloads across AWS, GCP, and on-prem. You want the same Kubernetes operational workflow everywhere. With KubeOne, you use the same tool, the same manifest structure, and the same `kubeone apply` command regardless of where the cluster lives. Only the Terraform layer changes. ## KubeOne vs Other Tools | Tool | Cloud Support | Bare Metal | Day-2 Ops | Approach | License | |------------------|--------------------|--------------|--------------------|---------------------------|------------| | **KubeOne** | All major clouds | First-class | Automated upgrades | Declarative YAML + SSH | Apache 2.0 | | **kubeadm** | Any | Yes (manual) | Manual | Imperative CLI | Apache 2.0 | | **kOps** | AWS (primary), GCP | No | Rolling updates | Declarative, cloud-native | Apache 2.0 | | **Rancher/RKE2** | All major clouds | Yes | Through Rancher UI | Rancher-managed | Apache 2.0 | | **Cluster API** | All major clouds | Experimental | Declarative | Kubernetes-native (CRDs) | Apache 2.0 | The main difference: KubeOne is the only tool that treats bare metal and cloud infrastructure equally, with full day-2 lifecycle automation. kubeadm gives you the building blocks but no automation. kOps is excellent for AWS but does not support bare metal. Cluster API is powerful but requires an existing management cluster and has limited bare metal support. > **Tip:** KubeOne and kOps serve different audiences. If you are AWS-only and want deep AWS integration, kOps is excellent. If you need bare metal, multi-cloud, or edge support, KubeOne is the better fit. See [KubeOne vs kOps](/learn/kubeone/kubeone-vs-kops/) for a detailed comparison. ## The Terraform Connection The relationship between KubeOne and Terraform deserves emphasis because it is central to how you will use KubeOne in practice. KubeOne deliberately does not provision infrastructure. Creating VMs, setting up load balancers, configuring networks — that belongs to Terraform (or your infrastructure tool of choice). This separation keeps both tools focused: Terraform manages infrastructure, KubeOne manages Kubernetes. The workflow looks like this: 1. Write Terraform configuration for your infrastructure (or use one of the official examples from the KubeOne repository). 2. Run `terraform apply` to create servers, load balancers, and networks. 3. Run `terraform output -json > tf.json` to export infrastructure details. 4. Run `kubeone apply --manifest kubeone.yaml -t tf.json` to install Kubernetes. When you need to upgrade Kubernetes, you update the version in your KubeOneCluster manifest and run `kubeone apply` again. When you need to add more servers, you update your Terraform configuration, apply it, and run `kubeone apply` to pick up the changes. For bare metal environments where servers already exist, you skip Terraform entirely and list your hosts directly in the KubeOneCluster manifest with their IP addresses and SSH credentials. ## Next Steps You now understand what KubeOne is, how it works, and where it fits. The next step is to get your hands on it. - [**Installing KubeOne: Your First Cluster in 15 Minutes**](/learn/kubeone/installing-kubeone-first-cluster/) — the next tutorial in this series walks you through installing KubeOne and provisioning your first cluster end-to-end. - If you already have bare metal servers ready, jump to [**Zero to Production: KubeOne on Bare Metal**](/learn/kubeone/kubeone-baremetal/) for a hands-on guide. - For Hetzner Cloud users, the Hetzner-specific guide covers provider configuration and cost-optimized setups. ## Summary KubeOne automates the full lifecycle of Kubernetes clusters — installation, upgrades, and repair — on any SSH-reachable infrastructure. It pairs with Terraform for infrastructure provisioning, uses kubeadm under the hood, and deploys machine-controller for declarative worker node management. If you need Kubernetes on bare metal, budget clouds, or edge hardware without paying for a managed service, KubeOne is the tool. #### Resources - [KubeOne Documentation](https://docs.kubermatic.com/kubeone/) - [KubeOne GitHub Repository](https://github.com/kubermatic/kubeone) #### On This Page - [Introduction](#introduction) - [What is KubeOne?](#what-is-kubeone) - [How KubeOne Works](#how-kubeone-works) - [KubeOneCluster Manifest](#kubeonecluster-manifest) - [Terraform Integration](#terraform-integration) - [SSH-Based Execution](#ssh-based-execution) - [machine-controller](#machine-controller) - [The Full Flow](#the-full-flow) - [Key Features](#key-features) - [When Should You Use KubeOne?](#when-should-you-use-kubeone) - [Bare Metal and Budget Clouds](#bare-metal-and-budget-clouds) - [Edge and IoT](#edge-and-iot) - [Multi-Cloud Consistency](#multi-cloud-consistency) - [KubeOne vs Other Tools](#kubeone-vs-other-tools) - [The Terraform Connection](#the-terraform-connection) - [Next Steps](#next-steps) - [Summary](#summary) --- ## What is KubeVirt? Running VMs on Kubernetes Explained - **URL:** https://www.kubermatic.com/learn/kubevirt/what-is-kubevirt/ - **Date:** 2026-04-30 [Learn](/learn/) / [Kubevirt](/learn/kubevirt/) / What is KubeVirt? Running VMs on Kubernetes Explained kubevirt # What is KubeVirt? Running VMs on Kubernetes Explained ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Mar 17, 2026 8 min read Beginner [getting-started](/learn/?tag=getting-started) [virtualization](/learn/?tag=virtualization) #### Prerequisites - Basic understanding of Kubernetes concepts (pods, nodes, deployments) - Familiarity with virtual machines and hypervisors ## Introduction Most organizations are not 100% containerized, and they probably never will be. You have legacy applications that assume a full operating system. You have Windows workloads that cannot run in a container. You have specialized software — think telecom network functions, database appliances, or machine learning toolkits — that needs direct hardware access and a traditional VM environment. For years, the answer was to maintain two separate stacks: a Kubernetes cluster for your containerized workloads, and a hypervisor platform (typically VMware vSphere) for your VMs. Two sets of tooling, two teams, two billing models. KubeVirt changes that equation. It extends Kubernetes to run virtual machines alongside your containers, on the same cluster, managed with the same API and tooling you already know. The timing matters too. Broadcom’s acquisition of VMware has reshaped the virtualization market. License costs have increased significantly, and many organizations are actively looking for alternatives to proprietary hypervisors. KubeVirt — a CNCF Incubating project backed by Red Hat, NVIDIA, Intel, and a large open-source community — has emerged as a serious contender. This guide explains what KubeVirt is, how it works under the hood, and when it makes sense to use it. ## What is KubeVirt? KubeVirt is an open-source project that adds virtual machine management capabilities to Kubernetes. Rather than replacing Kubernetes or building a separate platform, KubeVirt works as a Kubernetes extension — it introduces new custom resources (CRDs) that let you define, start, stop, and manage VMs using `kubectl` and the Kubernetes API. Here is what that means in practice: - **It is a Kubernetes-native solution.** You create a `VirtualMachine` YAML manifest the same way you create a Deployment. You apply it with `kubectl apply`. The VM shows up in your cluster alongside your pods. - **It uses KVM and libvirt under the hood.** These are the same battle-tested Linux virtualization technologies that power Google Cloud, AWS (Nitro is KVM-based), and most of the cloud industry. This is not experimental technology. - **It is a CNCF Incubating project.** KubeVirt graduated from the CNCF Sandbox and is on the path toward graduation. It has broad industry backing and an active contributor community. - **VMs and containers coexist.** A VM running on KubeVirt can communicate with pods over the same cluster network. You can put a VM-based database backend and a containerized API frontend in the same namespace with a Kubernetes Service in front of them. KubeVirt does not replace your container workloads. It gives Kubernetes the ability to handle the workloads that containers cannot. ## How KubeVirt Works KubeVirt’s architecture follows standard Kubernetes patterns — controllers, DaemonSets, and CRDs. If you understand how Kubernetes operators work, the architecture will feel familiar. ### Core Components **virt-controller** runs as a Deployment at the cluster level. It watches for `VirtualMachine` and `VirtualMachineInstance` custom resources. When you create a VM, virt-controller is responsible for creating the corresponding virt-launcher pod on an appropriate node. **virt-handler** runs as a DaemonSet on every node that should host VMs. It acts as the bridge between Kubernetes and the underlying virtualization layer. When a virt-launcher pod lands on a node, virt-handler configures the VM through libvirt and manages its lifecycle — start, stop, migrate, and monitor. **virt-launcher** is a pod that wraps a single VM. Each running VM gets its own virt-launcher pod, which contains the QEMU process that actually executes the virtual machine. From Kubernetes’ perspective, a VM is just a pod with resource requests. The scheduler places it, networking connects it, and monitoring observes it — all through the standard Kubernetes machinery. **CDI (Containerized Data Importer)** is a companion project that handles importing VM disk images into your cluster. It can pull QCOW2, ISO, VMDK, and raw disk images from HTTP endpoints, container registries, or S3-compatible storage, and write them into PersistentVolumes that your VMs use as disks. ### Architecture Flow Here is what happens when you create a virtual machine: ``` flowchart TD User["kubectl apply -f vm.yaml"] User --> Ctrl subgraph ControlPlane["Control plane"] Ctrl["virt-controller (Deployment)"] end Ctrl -->|creates VMI| API[(Kubernetes API)] Ctrl -->|schedules virt-launcher pod| Sched[kube-scheduler] subgraph Node["Worker node"] Launcher["virt-launcher pod (QEMU process)"] Handler["virt-handler (DaemonSet)"] Libvirt[libvirt + KVM] Handler --> Libvirt Libvirt --> Launcher end Sched --> Launcher Handler -.->|reports status| API Launcher -.->|mounts| PV[(PersistentVolumes = VM disks)] ``` The key insight: Kubernetes never needs to “know” about virtual machines in any special way. From the scheduler’s perspective, a virt-launcher pod is a pod that requests a certain amount of CPU, memory, and possibly devices (like a GPU). The virtualization happens inside the pod. > **Tip:** Because VMs run inside pods, all your existing Kubernetes tooling — monitoring with Prometheus, logging with Fluentd, network policies, RBAC — works with KubeVirt VMs out of the box. ## When Should You Use KubeVirt? KubeVirt is not the right choice for every situation. Here are three scenarios where it makes strong sense. ### 1. Legacy Application Modernization You have applications that cannot be containerized today — maybe they depend on specific kernel versions, require systemd, or run on Windows. Instead of maintaining a separate hypervisor cluster for these workloads, you run them as VMs on your existing Kubernetes infrastructure. This lets you consolidate infrastructure immediately while giving your teams time to modernize those applications at their own pace. The VM workloads use the same CI/CD pipelines, the same monitoring stack, and the same network policies as everything else. ### 2. VMware Exit Strategy Broadcom’s licensing changes have made VMware significantly more expensive for many organizations. If you are evaluating alternatives, KubeVirt offers a path that does not require buying into another proprietary hypervisor. KubeVirt runs on commodity Linux servers with KVM support — no per-socket licensing, no enterprise agreements. Your operations team manages VMs through the Kubernetes API instead of learning yet another management plane. Tools like the `forklift` project (another CNCF project) can help migrate existing VMware VMs to KubeVirt. > **Warning:** Migrating from VMware to KubeVirt is not a weekend project. Production migrations require careful planning around storage, networking, and VM compatibility. Evaluate your workloads thoroughly before committing. ### 3. Mixed Workloads on a Single Platform Some teams need VMs — data scientists running GPU-accelerated workloads with specific driver requirements, developers testing against multiple operating systems, or operations teams running network appliances that only ship as VM images. Other teams need containers. KubeVirt gives you one platform for both. Your platform team manages one cluster, one set of infrastructure, and one set of policies. Teams that need VMs get VMs. Teams that need containers get containers. Everyone uses `kubectl`. ## KubeVirt vs Other Approaches | Approach | Pros | Cons | Best For | |-----------------------------------------------|---------------------------------------------------------------|--------------------------------------------------|-------------------------------------------------| | **KubeVirt** | Open source, Kubernetes-native, CNCF project, no license fees | Requires KVM-capable nodes, younger ecosystem | Teams already running Kubernetes | | **OpenShift Virtualization** | Enterprise support, integrated with OpenShift | Requires OpenShift subscription | Red Hat shops needing vendor support | | **Proxmox** | Mature, solid web UI, easy to set up | Not Kubernetes-native, separate management plane | Small teams, homelab, standalone virtualization | | **Traditional hypervisors (VMware, Hyper-V)** | Proven at scale, feature-rich, deep ecosystem | Expensive licensing, separate tooling and teams | Enterprises locked into existing agreements | If you are already running Kubernetes and want to bring VMs into that ecosystem, KubeVirt is the most direct path. If you need enterprise support and are in the Red Hat ecosystem, OpenShift Virtualization (which is built on KubeVirt) is worth evaluating. If you have no Kubernetes footprint and just need virtualization, Proxmox or a traditional hypervisor may be simpler. ## Key Concepts Before you start working with KubeVirt, you need to understand four core resources. **VirtualMachine (VM)** is the persistent definition of your virtual machine. It includes the VM’s CPU, memory, disk, and network configuration. Think of it like a Deployment — it defines the desired state and survives restarts. When you set `running: true` on a VirtualMachine, KubeVirt creates the corresponding instance. **VirtualMachineInstance (VMI)** is the running instance of a VM. It is analogous to a Pod — it represents the actual running workload and is ephemeral. When you stop a VirtualMachine, the VMI is deleted. When you start it again, a new VMI is created. **DataVolume** manages the process of importing and preparing disk images for your VMs. It uses CDI under the hood. You point a DataVolume at a QCOW2 image URL, and it handles downloading the image, converting it, and writing it to a PersistentVolumeClaim that your VM can mount as a disk. **virtctl** is the KubeVirt CLI tool. While you can manage most VM lifecycle operations with `kubectl`, `virtctl` provides VM-specific commands that do not have a `kubectl` equivalent — things like opening a serial console (`virtctl console`), starting an SSH session (`virtctl ssh`), or live-migrating a VM between nodes (`virtctl migrate`). > **Tip:** You can install `virtctl` as a kubectl plugin via krew: `kubectl krew install virt`. This lets you use `kubectl virt` instead of `virtctl`. ## Next Steps Now that you understand what KubeVirt is and how it fits into the Kubernetes ecosystem, the next step is to set it up. Head to [Installing KubeVirt on a Kubernetes Cluster](/learn/kubevirt/installing-kubevirt/) to deploy KubeVirt on a test cluster and create your first virtual machine. If you are specifically planning a migration away from VMware, keep an eye out for the VMware to KubeVirt migration planning guide later in this series. ## Summary KubeVirt extends Kubernetes to run virtual machines alongside containers, using the production-proven KVM/libvirt virtualization stack. It is a CNCF Incubating project with broad industry support and an active community. If you have workloads that cannot be containerized — legacy applications, Windows VMs, or specialized software — KubeVirt lets you manage them on the same platform, with the same tools, and through the same API as the rest of your infrastructure. #### Resources - [KubeVirt Documentation](https://kubevirt.io/user-guide/) - [KubeVirt GitHub Repository](https://github.com/kubevirt/kubevirt) - [CNCF KubeVirt Project Page](https://www.cncf.io/projects/kubevirt/) #### On This Page - [Introduction](#introduction) - [What is KubeVirt?](#what-is-kubevirt) - [How KubeVirt Works](#how-kubevirt-works) - [Core Components](#core-components) - [Architecture Flow](#architecture-flow) - [When Should You Use KubeVirt?](#when-should-you-use-kubevirt) - [1. Legacy Application Modernization](#1-legacy-application-modernization) - [2. VMware Exit Strategy](#2-vmware-exit-strategy) - [3. Mixed Workloads on a Single Platform](#3-mixed-workloads-on-a-single-platform) - [KubeVirt vs Other Approaches](#kubevirt-vs-other-approaches) - [Key Concepts](#key-concepts) - [Next Steps](#next-steps) - [Summary](#summary) --- ## Meet KKP 2.30: More Support for AI Workloads, Gateway API, and Advanced Control - **URL:** https://www.kubermatic.com/blog/meet-kkp-2-30-more-support-for-ai-workloads-gateway-api-and-advanced-control/ - **Date:** 2026-04-30 - **Description:** Discover what's new in KKP 2.30: GPU cluster improvements, Gateway API, Grafana Alloy support, and more. - **Categories:** Products - **Tags:** KKP - **Authors:** Csenger Szabo We're happy to announce the release of **Kubermatic Kubernetes Platform (KKP) 2.30**! Over the past months, we have focused our engineering efforts on expanding capabilities and improving usability across the core platform and the KKP Dashboard. This release includes over 100 merged pull requests and focuses on three main areas: better support for AI workloads, modern traffic management with Gateway API, and stronger observability and operational control. Here's everything that's new. ## AI-Ready Infrastructure: Advanced GPU Machine Type Selector As AI appliances and machine learning workloads evolve, optimizing hardware allocation is critical. KKP 2.30 introduces an improved Machine Type Selector built specifically for GPU clusters. <img src="/static/kkp-2-30-ai-ready-infrastructure.png" alt="" width="800" height="604" loading="lazy" style="display:block;height:auto;margin:20px auto;"> It makes it easier to find and compare GPU-optimized instance types across providers, allowing you to provision clusters that match your workload requirements, without overprovisioning or wasted resources. ## Kubernetes MCP Server Integration In KKP 2.30, we have introduced the **Kubernetes MCP (Model Context Protocol) Server** as a deployable application. <img src="/static/kkp-2-30-mcp-server-integration.png" alt="" width="800" height="448" loading="lazy" style="display:block;height:auto;margin:20px auto;"> By deploying the MCP server, you can directly interface with and manage your KKP clusters using LLM-powered assistants. This opens the door to conversational operations and AI-assisted troubleshooting. You can read more about MCP server and how it can be useful to manage user-clusters in [this documentation page](https://docs.kubermatic.com/kubermatic/v2.30/architecture/concept/kkp-concepts/applications/default-applications-catalog/kubernetes-mcp-server/). ## Next-Generation Traffic Routing with Gateway API With [NGINX Ingress support retiring in March 2026](/blog/ingress-nginx-retiring-transition-to-gatewayapi-with-kubelb-cli/), KKP 2.30 introduces Gateway API support as a modern alternative for external traffic routing. - **IAP Integration**: We've added [Gateway API support to the IAP (Identity-Aware Proxy) chart](https://github.com/kubermatic/kubermatic/pull/15365), allowing your deployments to natively use `HTTPRoute` resources instead of standard Ingress objects. - **Easy Migration & Opt-in**: You can easily enable this via the `--enable-gateway-api` operator flag or by setting `migrateGatewayAPI: true` in your Helm values. ## Migration to Grafana Alloy With Grafana Agent reaching deprecation, KKP 2.30 is officially upgrading our User Monitoring, Logging, and Alerting (MLA) stack to **Grafana Alloy**. The migration from Promtail to Alloy for user-cluster MLA will be transparent to end-users as well as KKP administrators. In the future, we are also looking to exploit more features of Alloy. ## Advanced KubeVirt & KubeLB Capabilities Virtual Machines running natively on Kubernetes continue to be a massive focus for enterprise hybrid environments. In 2.30, we've enriched our **KubeVirt provider** capabilities: - **Custom Environment Variables for Machine Controller**: You can now inject new environment variables, like cluster ID and project ID directly into the KubeVirt provider via the machine controller that will be introduced as labels on the KubeVirt VMs. - **KubeLB Enhancements**: We've updated KubeLB to v1.3.1 and made the platform vastly more flexible. You can now override the image for the KubeLB Cloud Controller Manager (CCM) directly using `.spec.userCluster.kubelb` within your `KubermaticConfiguration`. ## Tighter Security, Authentication, & Identity Management Security and strict tenant isolation are never an afterthought. We've grouped a series of enhancements that give administrators much tighter control over authentication: - **OAuth2-Proxy Flexibility**: Users can now [pass additional configuration arguments directly to `oauth2-proxy` pods](https://github.com/kubermatic/kubermatic/pull/15241). This feature addresses some edge cases where Azure Entra was sending really long queryparams to oauth2-proxy and authentication was failing for seed mla and user-cluster mla endpoints. You can add extra args per IAP deployment or for all deployments globally. Check the linked PR for short example how to customize. - **Orphan Binding Cleanup**: We resolved a persistent edge case where deleting a User or Project left behind orphaned `UserProjectBinding` resources in the background. KKP 2.30 ensures your RBAC and multi-tenant environments stay pristine and secure. - **Partial Configurations of Cluster CR**: Component settings fields in Cluster CRD now [allow only relevant attributes to be specified](https://github.com/kubermatic/kubermatic/pull/15182), reducing the friction of partial configurations and policy template selectors across the API. The linked PR has [an example](https://github.com/kubermatic/kubermatic/pull/15182) to demonstrate how this change makes overriding easier for cluster specs. ## Deep Platform Polish & Stability A significant portion of this cycle went toward hardening the system, updating core dependencies, and upgrading the user experience: - **Cortex 1.16.1 Upgrades**: We've pushed a [crucial upgrade to Cortex](https://github.com/kubermatic/kubermatic/pull/15356) that squashes an issue where the `cortex-ingester` was consuming excessive storage space and throwing repeating log errors, significantly improving MLA stability. *Note*: Please also check the release notes for potential gotcha during upgrade. - **Control Plane Resiliency**: Administrators can now set [specific Toleration overrides directly for control plane components](https://github.com/kubermatic/kubermatic/pull/15248), giving you tighter placement control over critical cluster infrastructure. Due to this change, you can ensure that control-plane components of some high-priority user-cluster(s) are secured on some dedicated MachineDeployments. - **Storage Fixes**: For those running bleeding-edge clusters, we've completely resolved the `azurefile-csi` edge cases when running Kubernetes versions 1.32 and newer. More information in [this PR](https://github.com/kubermatic/kubermatic/pull/15162). ## Making UI and User Experience Even More Seamless You will notice various visual and workflow refinements resulting from a sweeping cleanup of dashboard components, making cluster creation, GPU allocation, and observability workflows snappier and more intuitive. **Project Search Improvements**: Project search now supports backend filtering by project fields, cluster name, and cluster ID for enhanced discoverability. <img src="/static/kkp-2-30-project-search.gif" alt="" width="800" height="221" loading="lazy" style="display:block;height:auto;margin:20px auto;"> **VSphere Cluster Tagging Enhancements**: Allows users to view predefined category tags for vSphere cluster tags and manually add additional tags as needed. <img src="/static/kkp-2-30-cluster-tag.gif" alt="" width="800" height="280" loading="lazy" style="display:block;height:auto;margin:20px auto;"> **Event Rate Limit Enhancements**: Dashboard now supports all limit types of the Kubernetes EventRateLimit admission plugin: Server, Namespace, User, and SourceAndObject, enabling flexible event rate limiting policies. **Admin Panel**: - Default: Either can be set default which will be applied when creating a new User Cluster - Enforced: Global Enforcement of Event Rate Limit Policies and once restricted it can't be modified or removed from cluster wizard. <img src="/static/kkp-2-30-event-rate-limit-config.gif" alt="" width="800" height="273" loading="lazy" style="display:block;height:auto;margin:20px auto;"> **White-Labeling Improvements**: Add support for easier white-labeling and branding of KKP. This allows customization of several UI elements, including the logo, colors, fonts, favicon, background, and page title. <img src="/static/kkp-2-30-white-labeling.png" alt="" width="800" height="256" loading="lazy" style="display:block;height:auto;margin:20px auto;"> **Improved Machine Type Selection UI in Cluster Creation**: Machine types are now presented in a structured, searchable, and filterable table with columns for instance name, vCPU, memory, and description. Users can filter between standard CPU and GPU-enabled instances (where supported). <img src="/static/kkp-2-30-advanced-machine-selectors.gif" alt="" width="800" height="482" loading="lazy" style="display:block;height:auto;margin:20px auto;"> **Make nftables as Default Proxy Mode**: Kubernetes 1.35+ clusters with non-Cilium CNI plugin now default to nftables instead of ipvs, aligning with upstream Kubernetes direction. <img src="/static/kkp-2-30-default-proxy-mode-nftables.gif" alt="" width="800" height="303" loading="lazy" style="display:block;height:auto;margin:20px auto;"> ## Updated lifecycle and platform support - **Kubernetes 1.35 Support**: Stay up-to-date with the latest from the community with added support for [Kubernetes version 1.35](https://kubernetes.io/blog/2025/12/17/kubernetes-v1-35-release/). ## Have a good time trying out the new features! We couldn't have done this without the continuous feedback from our incredible community. We hope you find these new features and improvements valuable for your projects! Thank you for being a part of the Kubermatic community, and we look forward to your feedback on KKP 2.30. You can find more details about this release in the [changelog](https://github.com/kubermatic/kubermatic/blob/release/v2.30/docs/changelogs/CHANGELOG-2.30.md#v2300). If you find our contributions valuable, we kindly encourage you to leave a star on our [GitHub repository](https://github.com/kubermatic/kubermatic). As always, please don't hesitate to reach out with any questions or suggestions via [Contact Us](/contact-us/) form. --- ## Zero to Production: KubeOne on Bare Metal - **URL:** https://www.kubermatic.com/learn/kubeone/kubeone-baremetal/ - **Date:** 2026-04-30 [Learn](/learn/) / [Kubeone](/learn/kubeone/) / Zero to Production: KubeOne on Bare Metal kubeone # Zero to Production: KubeOne on Bare Metal ![Abubakar Siddiq Ango](/static/authors/abubakar-ango.jpg) Abubakar Siddiq Ango Senior Developer Advocate Mar 1, 2026 3 min read Intermediate [bare-metal](/learn/?tag=bare-metal) [production](/learn/?tag=production) [getting-started](/learn/?tag=getting-started) #### Prerequisites - 3 bare-metal servers (or VMs) with Ubuntu 22.04 - A load balancer (hardware, HAProxy, or keepalived+HAProxy) fronting the control plane on TCP 6443 - SSH access with key-based authentication - kubectl installed on your local machine - Basic Kubernetes knowledge ## Introduction KubeOne is Kubermatic’s open-source tool for automating the full lifecycle of Kubernetes clusters. In this tutorial, you’ll go from bare metal servers to a production-ready cluster. ## Step 1: Install KubeOne Download the latest KubeOne binary for your platform: ```bash curl -sfL https://get.kubeone.io | sh kubeone version ``` ## Step 2: Prepare Your Infrastructure On bare metal, you skip Terraform entirely — your servers already exist. You do, however, need one piece of infrastructure in front of the control plane: a load balancer. This is non-negotiable for HA, because `kubectl` and every worker node need a single stable address to talk to, not three separate control plane IPs. The simplest open-source option is HAProxy on a separate small VM (or two, with keepalived for the VIP) forwarding TCP 6443 to all three control plane nodes. For this tutorial we’ll assume your load balancer is reachable at `api.production-edge.example.com`. The HA topology looks like this: ``` flowchart TD Client["kubectl / workers"] LB["Load balancer api.production-edge.example.com:6443"] Client --> LB LB --> CP1["control-plane-1 203.0.113.10 kube-apiserver + etcd"] LB --> CP2["control-plane-2 203.0.113.11 kube-apiserver + etcd"] LB --> CP3["control-plane-3 203.0.113.12 kube-apiserver + etcd"] CP1 <-.->|etcd raft| CP2 CP2 <-.->|etcd raft| CP3 CP1 <-.->|etcd raft| CP3 ``` > **Warning:** Ensure all servers can communicate with each other on the private network. Firewall rules must allow Kubernetes API (6443), etcd (2379-2380), and kubelet (10250) traffic between the control plane nodes, plus 6443 from the load balancer to each control plane node. ## Step 3: Create the KubeOne Configuration ```yaml apiVersion: kubeone.k8c.io/v1beta2 kind: KubeOneCluster name: production-edge versions: kubernetes: "v1.30.2" cloudProvider: none: {} apiEndpoint: host: "api.production-edge.example.com" port: 6443 controlPlane: hosts: - publicAddress: "203.0.113.10" privateAddress: "10.0.0.10" sshUser: "ubuntu" - publicAddress: "203.0.113.11" privateAddress: "10.0.0.11" sshUser: "ubuntu" - publicAddress: "203.0.113.12" privateAddress: "10.0.0.12" sshUser: "ubuntu" ``` The `apiEndpoint` block is what makes this cluster actually HA. KubeOne writes that hostname into the generated kubeconfig and into every worker node’s kubelet config, so every API call hits the load balancer and can reach any healthy control plane node. Omit it and you’ll get three control plane nodes that nobody can failover between. ## Step 4: Provision the Cluster ```bash kubeone apply --manifest kubeone.yaml ``` KubeOne will: 1. Install container runtime (containerd) 2. Bootstrap the first control plane node 3. Join remaining control plane nodes 4. Configure networking (Canal CNI by default) 5. Deploy machine-controller for worker nodes ## Step 5: Verify Your Cluster ```bash export KUBECONFIG=$PWD/production-edge-kubeconfig kubectl get nodes kubectl get pods -A ``` You should see all three control plane nodes in `Ready` state. ## Next Steps - Add worker nodes using MachineDeployments - Configure persistent storage with a CSI driver - Set up monitoring with Prometheus and Grafana - Enable cluster autoscaling ## Summary You’ve successfully provisioned a highly available Kubernetes cluster on bare metal using KubeOne. The cluster is production-ready with three control plane nodes for fault tolerance. #### Resources - [KubeOne Documentation](https://docs.kubermatic.com/kubeone/) - [Terraform Provider for KubeOne](https://github.com/kubermatic/kubeone) #### On This Page - [Introduction](#introduction) - [Step 1: Install KubeOne](#step-1-install-kubeone) - [Step 2: Prepare Your Infrastructure](#step-2-prepare-your-infrastructure) - [Step 3: Create the KubeOne Configuration](#step-3-create-the-kubeone-configuration) - [Step 4: Provision the Cluster](#step-4-provision-the-cluster) - [Step 5: Verify Your Cluster](#step-5-verify-your-cluster) - [Next Steps](#next-steps) - [Summary](#summary) --- ## Whitepaper Kubermatic SecureGuard - **URL:** https://www.kubermatic.com/whitepaper-kubermatic-secureguard/ - **Date:** 2026-04-28 - **Description:** Protect and manage secrets with open-source transparency. Learn all about SecureGuard. # Kubermatic SecureGuard Secure and automate how your teams manage secrets without compromise ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Protect and manage secrets with open-source transparency As organizations scale their cloud-native footprints, managing the “keys to the kingdom” - passwords, database credentials, and API keys - has become a major operational hurdle. Fragmented secret management often forces a choice between security and velocity, leading to manual bottlenecks or dangerous exposure. The industry is currently facing a critical implementation gap: **While 72% of development teams agree that secrets management tools help prevent data breaches, more than (52%) still do not have a secure solution in place.** *Businesswire, Compromised Secrets* This lack of adoption has severe consequences: nearly a quarter of developers have already experienced a data breach related to compromised credentials ([Businesswire](https://www.businesswire.com/news/home/20230822026925/en/Compromised-Secrets-Nearly-25-Percent-of-Developers-Have-Experienced-a-Data-Breach)). **Kubermatic SecureGuard** is a next-generation secrets management platform that bridges this gap. ## What is Kubermatic SecureGuard? **Kubermatic SecureGuard** is an open-source, production-grade secrets management platform specifically designed for the complexities of modern, Kubernetes-native environments. It acts as a centralized security hub that bridges the gap between high-security cryptographic storage and the dynamic needs of distributed applications. By merging the cryptographic hardening of [OpenBao](https://github.com/openbao/openbao) with the native orchestration of the [External Secrets Operator (ESO)](https://github.com/external-secrets/external-secrets), **KubeSG** provides a unified, self-hosted transport layer for secrets. It empowers organizations to centralize security policy while decentralizing delivery, ensuring that application identities remain secure without slowing down development. ### The Value of Open-Source Secrets Management In an era of shifting software licenses, **KubeSG** guarantees operational continuity. By leveraging OpenBao, we ensure your secrets management stack remains truly open-source, protecting you from sudden vendor pricing hikes or license lock-in. ## Key Organizational Roles **KubeSG** is designed to optimize the workflows of three critical roles: ![](/static/phone-policeman-lock.png) ### Security Teams Responsible for the organization's security posture, architects use **KubeSG** to establish a single source of truth and enforce least-privilege access via fine-grained RBAC. ![](/static/monitor-rocket-gears.png) ### DevOps & Platform Teams These teams leverage **KubeSG** to automate the secrets lifecycle, eliminating manual ticketing and enabling "breakage-free" rotation across thousands of clusters. ![](/static/woman-with-building-blocks.png) ### Developers As the primary users, developers gain immediate, native access to the credentials they need (including AI tokens and API keys) directly within Kubernetes, allowing them to focus on code, not infrastructure. By removing manual friction, teams can reclaim significant time. **Currently, developers spend an average of 3 hours per week on secret-related tasks, costing a 10-person team approximately €172,000 annually in lost productivity.** *The Stack, Secret sprawling is costing you more than you think* ## Key Benefits ### Centralized Governance Stop the sprawl of secrets across different platforms. **KubeSG** unifies secret management across multi-cloud and hybrid environments, providing a single control point and a comprehensive audit trail. This aligns with the industry shift toward “centralized governance over distinct decentralized secrets management vaults” ([Gartner](https://www.gartner.com/en/documents/5666155)). ### Lifecycle Automation Eliminate the risks and hassle of manual credential handling. By automating the entire lifecycle, **KubeSG** ensures that credentials remain valid and secure without manual intervention or service interruptions. ### Transparency and trust Security shouldn’t be a black box. Built on open-source solutions, **KubeSG** offers full visibility into its security model and code, avoiding the restrictive licensing and cost forecasting difficulties typical of proprietary tools ([Gartner](https://www.gartner.com/en/documents/5666155)). ## Production-Grade Infrastructure KubeSG builds on the strengths of the CNCF ecosystem to offer a scalable, Kubernetes-native platform. ![](/static/icons/dumbbell-icon.svg) ### Kubernetes-Powered Infrastructure At its core, **KubeSG** leverages native Kubernetes APIs. This ensures integration with your existing cloud-native stack, allowing secrets to be injected into workloads as standard environment variables or files. ![](/static/icons/robot-icon.svg) ### AI-Ready Infrastructure **KubeSG** is built for the AI era. It provides a specialized environment to centrally manage and rotate high-value AI tokens and API access keys, ensuring that the infrastructure powering your LLMs remains secure. This eliminates the risk of hard-coded token leaks that lead to uncontrolled API costs. ![](/static/struct-grad-icon.svg) ### Multi-Tenancy and Isolation **KubeSG** enables large organizations to securely isolate multiple teams. Each tenant operates within a secure environment with its own isolated secret stores and access policies. This follows [Gartner's recommendation](https://www.gartner.com/en/documents/5666155) to "resist the urge to standardize on one secrets vault product" and instead prepare to manage secrets across multiple isolated environments to limit the blast radius. The detailed features can be found in the [solution brief](/solution-brief-kubermatic-secureguard/). ## Technical & Business Benefits ### Reduced Breach Risk Stolen credentials are the #1 access vector for breaches, accounting for 22% of all breaches ([Verizon](https://www.verizon.com/business/resources/reports/dbir/)). Furthermore, the global average cost per breach was about **$4.44 million** in 2025 ([IBM](https://www.ibm.com/reports/data-breach)). With **KubeSG**, identity-based access and automated rotation minimize the window of vulnerability for compromised credentials. ### Improved Velocity **KubeSG** removes the wait times that slow down your team. Instead of filing tickets and waiting days for manual security approvals, developers get instant, automated access to the credentials they need so they can keep shipping code. ### Compliance Readiness Centralized auditing and policy enforcement make it easy to prove you are meeting strict standards like SOC 2, HIPAA, and PCI-DSS, without having to manually search for logs across different systems. ### Cost Efficiency By automating the manual heavy lifting that usually eats up engineering hours, you reduce operational overhead and can reinvest those savings back into your core product. ## Conclusion In a landscape where credentials are the primary target for attackers, KubeSG ensures your "keys to the kingdom" are managed with the same rigor and visibility as your code. By moving secrets management into a transparent, Kubernetes-native environment, organizations can finally stop choosing between moving fast and staying safe. Whether you are managing a few database keys or a sprawling fleet of AI-driven applications, KubeSG stands ready to protect your secrets. Safely, with open-source transparency. ## About Kubermatic Kubermatic is a leader in Kubernetes and cloud-native technologies, dedicated to empowering organizations with advanced solutions that simplify and optimize IT management. Our products are designed to meet the needs of modern enterprises, providing the tools and support necessary to drive innovation and achieve business success. Reach out to us on the button below for more information about Kubermatic solutions! [Talk to Us Now!](/demo/) --- ## Introducing The Control Plane Newsletter - **URL:** https://www.kubermatic.com/blog/the-control-plane-issue-1/ - **Date:** 2026-04-30 - **Description:** The Control Plane is a monthly newsletter for Platform Engineers and SREs. Issue 1 - data sovereignty in Kubernetes and the decoupled control plane pattern. - **Categories:** Best Practices - **Tags:** Kubernetes, Newsletter - **Authors:** Abubakar Siddiq Ango If you run Kubernetes in production, you already know the gap between "getting started" content and the problems you actually face at scale. Most newsletters land somewhere in between: curated link dumps with no opinion, or vendor pitches disguised as thought leadership. The Control Plane is something different. Once a month, we publish a well-researched deep dive into a topic that matters to Platform Engineers and SREs, along with curated industry signals, Kubermatic product updates, and the occasional war story from the field. ## What's in Issue #1 [Read our first issue](https://kubermatic-4550048.hs-sites.com/80b-on-sovereign-cloud-air-gapped-gitops-patterns-your-idp-is-in-virginia), where we tackled **data sovereignty in Kubernetes**, a topic that went from "nice to have" to "board-level priority" faster than most teams were prepared for. ### Your Sovereign Cloud Has a Virginia Problem The sovereign cloud market crossed $80 billion in 2026. Organizations are spending aggressively to comply with the EU Data Act, DORA, and a growing list of data residency laws. But spending is not the same as compliance. The most common failure mode: data sits in the correct jurisdiction while the control plane, identity provider, and key management live somewhere else entirely. When AWS US-East-1 failed in October 2025, European services with data in Frankfurt went offline because their IAM depended on a region in Virginia. In the deep dive, we walk through the **decoupled control plane pattern** (Seed/User cluster architecture), a **Kyverno policy** that geofences workloads to specific regions, and the **Hold Your Own Key (HYOK)** approach to encryption key management. ### Also in this issue - **War Story** — A European financial services company learned that sovereignty has three layers (data, compute, and identity) when an outage in Virginia took down their "sovereign" Frankfurt clusters. - **Kubermatic Releases** — KubeLB v1.3 ships with WAF support, Gateway API migration, and supply chain security. KKP v2.29.4 adds Kubernetes v1.34.4 support and Gateway API as an alternative to NGINX Ingress. - **Control Plane Radar** — Curated reads on the EU Data Act, DORA's concentration risk requirements, the $80B sovereign cloud market, and multi-cluster network policies with Cilium ClusterMesh. - **Community & Events** — KubeCon Amsterdam is next month. ContainerDays Hamburg CFP closes February 28. ## Subscribe The Control Plane ships once a month. No spam. <script charset="utf-8" type="text/javascript" src="//js.hsforms.net/forms/embed/v2.js"></script> <script> hbspt.forms.create({ portalId: "4550048", formId: "774d7fa4-cb63-4643-ab4d-008fbde3e744", region: "na1" }); </script> --- ## Ingress NGINX is Retiring: Use KubeLB to Transition to Gateway API - **URL:** https://www.kubermatic.com/blog/ingress-nginx-retiring-transition-to-gatewayapi-with-kubelb-cli/ - **Date:** 2026-04-30 - **Description:** Ingress NGINX retires March 2026. You should migrate to Gateway API and how KubeLB's CLI and Dashboard automate the conversion process. - **Categories:** Products - **Tags:** KubeLB - **Authors:** Abubakar Siddiq Ango If you’re running Ingress NGINX in production, the clock is officially ticking. With maintenance set to permanently conclude in [March 2026](https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/), the Kubernetes project has retired the ingress-nginx controller. After the deadline, there will be zero security patches, zero bug fixes, and zero new releases. Leaving your traffic management on autopilot is no longer a luxury; it’s a massive security risk. In the recently released KubeLB 1.3.1, we [resolved 4 CVEs](https://docs.kubermatic.com/kubelb/v1.3/release-notes/#ingress-nginx-4141--4143) with [CVSS score of 8.8](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), which further stresses the need to transition to [Gateway API](https://gateway-api.sigs.k8s.io/). ## Why Gateway API? The official replacement for the Ingress API is the [Gateway API](https://gateway-api.sigs.k8s.io/), which is a major enhancement: **Role-based architecture.** Gateway API introduces three layers — GatewayClass, Gateway, and Routes — that map cleanly to organizational roles. GatewayClasses and Gateways are managed by infrastructure teams. Routes are managed independently by application teams. Ingress never had this separation of concerns. **Multi-protocol support.** The Gateway API natively supports HTTP, HTTPS, gRPC, TCP, and UDP routing using typed Route resources (HTTPRoute, GRPCRoute, TCPRoute, etc.), whereas Ingress was effectively HTTP-only. **Richer traffic management.** Header-based routing, traffic splitting, request mirroring, and URL rewrites are all part of the standard API — no more controller-specific annotations. **Standardized across implementations.** The Gateway API is implementation-agnostic. The API is the same whether you select Envoy Gateway, Cilium, Istio, or another provider. Your manifests are portable. ## How KubeLB Can Help Manually switching from Ingress to Gateway API means: - Converting every Ingress resource to a Gateway + HTTPRoute pair - Managing the migration of TLS certificates - Planning DNS cutover (Gateway creates a new LoadBalancer with a new IP) - Testing everything before changing traffic KubeLB v1.3 takes care of this for you with its [automated Ingress-to-Gateway-API converter](https://docs.kubermatic.com/kubelb/v1.3/ingress-to-gateway-api/). You can use it through the KubeLB Dashboard or the CLI, and it handles converting ingress-nginx resources to Envoy Gateway format — the approach we recommend. ### What the Converter Does - Audits your cluster to determine the conversion status of all Ingress resources - Previews the precise Gateway API YAML that will be generated — before making any changes - Converts Ingress resources into Gateway + HTTPRoute resources - Copies TLS secrets to the Gateway namespace - Generates Envoy Gateway policies where needed - Tracks conversion status per resource (`new`, `pending`, `converted`, `partial`, `failed`, `skipped`) ### What You Need to Plan For **New IP address.** A new external IP is created when the Gateway establishes a new LoadBalancer Service. You'll need a DNS cutover plan: - **Blue-green:** Set up the Gateway alongside Ingress, verify, and then switch DNS - **Gradual:** Reduce DNS TTL values prior to migration, and switch one hostname at a time - **Automated with external-dns (recommended):** If you're using [external-dns](https://docs.kubermatic.com/kubelb/v1.3/ingress-to-gateway-api/external-dns/), configure it to watch both Ingress and Gateway API sources simultaneously. This lets external-dns manage DNS records for both resource types during the transition — no manual DNS updates, no resolution gaps. Once migration is complete, remove the Ingress sources from external-dns. This is the lowest-risk approach. **TLS certificates.** Certificates that are already in place won't transfer automatically. To issue fresh certificates for Gateway resources, you will need [cert-manager](https://docs.kubermatic.com/kubelb/v1.3/ingress-to-gateway-api/cert-manager/) if you are using it. To prevent validation outages during the transfer, consider using DNS01 challenges. **No canary between old and new.** Traffic cannot be divided between Ingress and Gateway. All-or-nothing switching for each hostname is managed via DNS. Plan accordingly. If you use external-dns with dual sources, this becomes less painful — DNS updates happen automatically as you convert each resource. ## Transition with the KubeLB CLI ![CLI](https://docs.kubermatic.com/img/kubelb/common/cli/cli-conversion-demo.gif) You can install [KubeLB CLI](https://docs.kubermatic.com/kubelb/v1.3/cli/) using the following command: ```bash go install github.com/kubermatic/kubelb-cli@v0.2.0 ``` ### Using the KubeLB Dashboard Prefer a visual interface? The KubeLB Dashboard offers the same conversion capabilities with a graphical UI: ```bash kubelb serve # Opens at localhost:8080 ``` **Using the KubeLB Dashboard to Migrate Ingress to Gateway API** ![Dashboard](https://docs.kubermatic.com/img/kubelb/common/cli/ingress-conversion-ui.gif) ### Using CLI #### Step 1: Audit Your Ingress Resources See what you're working with: ```bash # List all Ingress resources across all namespaces kubelb ingress list -A ``` This displays the current conversion status for each Ingress resource. You'll see right away which ones need attention. #### Step 2: Preview the Conversion Before changing anything, preview what the converter will generate: ```bash # Preview a single Ingress resource kubelb ingress preview my-app -n default # Preview all resources across all namespaces kubelb ingress preview -A ``` Without changing your cluster, this produces the Gateway API YAML that *would* be generated, including the Gateway, HTTPRoute, TLS secrets, and policies. Review it. Validate it. Share it with your team. #### Step 3: Convert Once you're comfortable, run the conversion: ```bash # Convert a single resource kubelb ingress convert my-app -n default # Convert everything (dry-run first!) kubelb ingress convert --all --dry-run -A # Convert everything for real kubelb ingress convert --all -A ``` You can also export manifests to files for GitOps workflows: ```bash kubelb ingress convert --all -A --output-dir ./gateway-manifests ``` #### Step 4: Skip What Shouldn't Be Converted Some Ingress resources might need to stay as-is — maybe they use a different controller. Annotate them to skip: ```bash kubectl annotate ingress my-legacy-app kubelb.k8c.io/skip-conversion=true ``` ## A Recommended Migration Strategy Here's the strategy we recommend based on our experience: 1. **Audit** — To determine your scope, run `kubelb ingress list -A` 2. **Set up external-dns dual sources** — If using external-dns, [add Gateway API sources](https://docs.kubermatic.com/kubelb/v1.3/ingress-to-gateway-api/external-dns/) alongside your existing Ingress sources. This automates DNS management during the transition 3. **Start in staging** — Convert non-production environments first. The converter is in beta; validate in a safe environment 4. **Preview everything** — Prior to each conversion, use `kubelb ingress preview` 5. **Lower DNS TTLs** — A few days before the actual cutover, lower your DNS TTL values 6. **Convert and validate** — Execute the conversion, confirm that the Gateway resources are healthy and routing correctly 7. **Switch DNS** — If using external-dns, this happens automatically. Otherwise, update DNS records to point to the new Gateway LoadBalancer IP 8. **Monitor** — Keep an eye on traffic, error rates, and certificate status 9. **Clean up** — Once stable, remove the old Ingress resources, Ingress NGINX controller, and Ingress sources from external-dns ## Don't Wait Running an unpatched Ingress controller is a liability, even if your current deployments won't break overnight. The switch to Gateway API represents a move to a more capable, secure, and sustainable routing architecture — not merely swapping out one controller for another. KubeLB's migration tooling takes the pain out of this transition. Audit your resources, preview the changes, and convert at your own pace. **References:** - [KubeLB Ingress to Gateway API Migration Guide](https://docs.kubermatic.com/kubelb/v1.3/ingress-to-gateway-api/) - [KubeLB CLI Reference](https://docs.kubermatic.com/kubelb/v1.3/cli/ingress-to-gateway-api/) - [Kubernetes Ingress NGINX Retirement Announcement](https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/) - [Kubernetes Steering Committee Statement](https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/) --- ## Solution Brief Kubermatic SecureGuard - **URL:** https://www.kubermatic.com/solution-brief-kubermatic-secureguard/ - **Date:** 2026-04-28 - **Description:** Discover how SecureGuard simplifies secure secret handling. # Kubermatic SecureGuard Secure and automate how your teams manage secrets without compromise ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Secure and Automate How Your Teams Manage Secrets Every modern platform runs on secrets: API keys, database passwords, certificates, and tokens. They unlock production systems, customer data, and AI workloads. They are also one of the easiest ways into your infrastructure. **Stolen credentials are now the #1 access vector for breaches, accounting for 22% of all breaches** Verizon, 2025 Data Breach Investigations Report At the same time, secret handling drains engineering time, with developers losing an average of 3 hours per week dealing with manual secret management. Secrets are both a security risk and an operational challenge. **Kubermatic SecureGuard** provides a Kubernetes-native way to manage them. ## What is Kubermatic SecureGuard? **Kubermatic SecureGuard** is a secrets management platform that acts as a secure transport layer for secrets in cloud-native and traditional environments. Built on **OpenBao** and integrated with the **External Secrets Operator (ESO)**, **KubeSG** automates the full lifecycle of secrets, and delivers credentials directly into Kubernetes. It brings **governance, transparency, and automation** to one of the most critical layers of modern infrastructure: application identities. ## Technical Foundations KubeSG is built on open-source components maintained by the community. This makes its security model transparent, auditable, and free from closed or proprietary modules. ![OpenBao logo](/static/openbao-logo.svg) ### OpenBao Core A community-led, secure backend providing encryption-as-a-service, fine-grained access control, and immutable audit logs. ![External Secrets Operator logo](/static/eso-logo.svg) ### ESO Integration KubeSG leverages the External Secrets Operator to synchronize secrets directly into Kubernetes. This allows developers to interact with standard Kubernetes Secret objects while the "heavy lifting" of synchronization and security happens in the background. ## Key Features ### OpenBao Core Engine A community-led backend providing encryption-as-a-service, secure storage, and detailed audit logs. ### ESO Integration Use the External Secrets Operator to sync secrets directly into Kubernetes without requiring custom app SDKs. ### "Breakage-Free" Rotation Automate the update of database passwords and API keys without requiring application restarts. ### Native Kubernetes Experience Developers interact with standard `Secret` objects, making security invisible to their daily workflow. ### Auto-Unsealing & Initialization Eliminates manual overhead by automatically managing the secrets backend lifecycle across cloud providers. ### Highly Customizable Adjusts to your organizational structure, supporting various storage backends (S3, GCS, Azure, Raft) and authentication methods. ## Key Benefits ### Automated Lifecycle & "Breakage-Free" Rotation KubeSG automates the entire lifecycle: storage, delivery, rotation, and auditing. Because it integrates natively with Kubernetes, it enables breakage-free secret rotation. Applications receive updated credentials automatically without requiring a manual restart or code changes. ### Built for the AI Era As organizations deploy Large Language Models (LLMs), managing AI API keys and tokens becomes a critical risk. KubeSG provides a centralized vault to store and rotate AI-specific secrets, ensuring your sensitive prompts and data streams remain protected. ### Native Experience, No SDKs We believe security should be invisible to the developer. KubeSG delivers secrets natively within Kubernetes. There are no proprietary SDKs to learn, and no app rewrites required. Just secure, identity-based access to the data your code needs. ### Open Governance & Cost Efficiency Proprietary tools impose restrictive licensing and “black box” security modules. Openbao and ESO are transparent and community-driven. This eliminates vendor lock-in and significantly lowers the Total Cost of Ownership (TCO) compared to enterprise-licensed alternatives. ## Designed for real-world teams ![](/static/phone-policeman-lock.png) ### Security & Platform teams Gain a single place to define policies, audit access, and reduce blast radius. ![](/static/monitor-rocket-gears.png) ### DevOps teams Automate secret delivery and rotation instead of running tickets and scripts. ![](/static/woman-with-building-blocks.png) ### Developers Simply get the secrets they need, inside Kubernetes, and stay focused on shipping code. For details about the benefits of KubeSG for different teams, please see our [full whitepaper](/whitepaper-kubermatic-secureguard/). ## In sum: More Security, More Transparency Kubermatic SecureGuard is the Kubernetes-native alternative to the status quo. It is designed for organizations that refuse to choose between the speed of automation and the security of a hardened, transparent vault. **Secure and automate how your teams manage secrets. Keep them safe with open-source transparency.** ## About Kubermatic Kubermatic is a leader in Kubernetes and cloud-native technologies, dedicated to empowering organizations with advanced solutions that simplify and optimize IT management. Our products are designed to meet the needs of modern enterprises, providing the tools and support necessary to drive innovation and achieve business success. Reach out to us on the button below for more information about Kubermatic solutions! [Talk to Us Now!](/demo/) --- ## Software Defined Automation: Scalable Seamless, Industry ready [DE] - **URL:** https://www.kubermatic.com/resources/software-defined-automation-scalable-seamless-industry-ready-de/ - **Date:** 2026-02-05 - **Description:** Let's explore the core of Software Defined Automation (SDA). # Software Defined Automation: Scalable Seamless, Industry ready \[DE] ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Tobias and Laurids' talk at SPS Nuremberg 2025 Today’s industrial automation environments are tightly bound to hardware and specific vendor ecosystems. This leads to long lifecycle lock-ins, poor scalability, and high maintenance costs. Software-defined approaches aim to break this dependency by decoupling automation workloads from dedicated hardware, enabling flexible deployment, scalability, and modern lifecycle management similar to IT. This project proves that industrial automation can break free from hardware lock-in by running on a flexible, software-defined IT/OT stack. In this talk, we explore the core of Software Defined Automation (SDA). We cover the following topics: - Why traditional hardware silos are holding back innovation - The “Edge Device Zoo”: The problem with proprietary digital solutions - How to create a true ecosystem where sensors and actuators work in harmony through software Watch this talk at SPS 2025 Nuremberg — Smart Product Solutions, hosted by the Open Industry 4.0 Alliance. **Speakers:** **Tobias Schneck - Principal Software Architect at Kubermatic** **Laurids Beckhoff - Process Industry Management at Beckhoff Automation** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Introducing KubeLB 1.3: Advanced Security with WAF, Seamless Gateway API Migration, and Supply Chain Integrity - **URL:** https://www.kubermatic.com/blog/kubelb-v1-3-advanced-security-with-waf-seamless-gateway-api-migration-and-supply-chain-integrity/ - **Date:** 2026-04-30 - **Description:** KubeLB 1.3 is live. Explore all the new features including Web Application Firewall, Ingress to Gateway API Migration, and more! - **Categories:** Company - **Tags:** KubeLB, Announcements - **Authors:** Waleed Malik We are proud to announce the release of **KubeLB 1.3**! This release represents a significant leap forward in securing your edge infrastructure and modernizing your traffic management. From introducing a powerful Web Application Firewall (WAF) to streamlining the transition to the Gateway API, KubeLB 1.3 is designed to help you build safer, more resilient platforms ## Release Highlights of KubeLB 1.3 ### Web Application Firewall (WAF) KubeLB has introduced Web Application Firewall (WAF) capabilities as an Enterprise Edition (EE) **Alpha** feature. With KubeLB WAF, you can protect your applications from SQL injection, XSS, and other injection attacks without application changes from a single point of control. Learn more in the KubeLB [Ingress to Gateway API Converter how-to](https://docs.kubermatic.com/kubelb/v1.3/ingress-to-gateway-api). ### Ingress to Gateway API Migration The Kubernetes ecosystem is rapidly adopting the [Gateway API](https://gateway-api.sigs.k8s.io/) as the new standard for traffic management, offering far greater expressiveness and extensibility than traditional Ingress. This shift is critical as the community has announced that [ingress-nginx](https://github.com/kubernetes/ingress-nginx) has entered **retirement mode** and will reach [End of Life (EOL) in March 2026](https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/). After this date, it will receive no further security patches or bug fixes. For a deeper understanding of the security and maintenance implications driving this change, we highly recommend reading the [Statement from the Kubernetes Steering and Security Response Committees](https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/). However, migrating existing resources manually is often complex and error-prone. To bridge this gap and accelerate your modernization journey, KubeLB 1.3 introduces an automated **conversion tool** as a **Beta Feature**. Learn more in the KubeLB [Ingress to Gateway API Converter how-to](https://docs.kubermatic.com/kubelb/v1.3/ingress-to-gateway-api). ### Supply Chain Security KubeLB v1.3 introduces comprehensive supply chain security for both Community Edition (CE) and Enterprise Edition (EE): - **Artifact Integrity**: Includes SBOM Generation (SPDX format) and **Keyless Artifact Signing** via Sigstore Cosign for all binaries, images, and Helm charts. - **Automated Vetting**: Features automated **Vulnerability Scanning** (blocking releases on HIGH/CRITICAL findings) and Dependency Monitoring. - **Compliance**: These measures ensure compliance with NTIA Minimum Elements, Executive Order 14028, and SLSA guidelines. Learn more in the [Supply Chain Security documentation](https://docs.kubermatic.com/kubelb/v1.3/security). ## KubeLB Enterprise Edition (EE) Features - [Web Application Firewall (WAF)](https://docs.kubermatic.com/kubelb/v1.3/tutorials/web-application-firewall/): WAF capabilities as an **Alpha** feature. - [Circuit Breakers](https://docs.kubermatic.com/kubelb/v1.3/tutorials/envoy-proxy/circuit-breakers/): Configurable circuit breakers for Envoy Clusters at Global or Tenant level. - [Traffic Policies](https://docs.kubermatic.com/kubelb/v1.3/tutorials/gatewayapi/backend-traffic-policy/): Support for Envoy Gateway's [BackendTrafficPolicy](https://docs.kubermatic.com/kubelb/v1.3/tutorials/gatewayapi/backend-traffic-policy/) and [ClientTrafficPolicy](https://docs.kubermatic.com/kubelb/v1.3/tutorials/gatewayapi/client-traffic-policy/). - [Metrics](https://docs.kubermatic.com/kubelb/v1.3/tutorials/observability/metrics-and-dashboards/): Additional metrics for Connection Manager and EE components. ## KubeLB Community Edition (CE) Features - [Ingress to Gateway API Migration (Beta)](https://docs.kubermatic.com/kubelb/v1.3/ingress-to-gateway-api/): Automated conversion from Ingress to Gateway API resources. - [Observability](https://docs.kubermatic.com/kubelb/v1.3/tutorials/observability/): Prometheus metrics for CCM, Manager, and Envoy Control Plane. Grafana dashboards for monitoring KubeLB components. - **Revamped E2E Tests**: E2E tests revamped to use chainsaw framework, now running in CI/CD pipeline. - [Graceful Envoy Shutdown](https://docs.kubermatic.com/kubelb/v1.3/tutorials/envoy-proxy/graceful-shutdown/): Envoy Proxy gracefully drains listeners before termination to avoid downtimes. - [Overload Manager](https://docs.kubermatic.com/kubelb/v1.3/tutorials/envoy-proxy/overload-manager/): Configurable overload manager and global connection limits using custom Envoy bootstrap. - [Custom Envoy Image](https://docs.kubermatic.com/kubelb/v1.3/references/ce#envoyproxy): Custom Envoy Proxy image through the EnvoyProxy configuration. ## KubeLB Security and Compliance ### Security Due to CVEs announced on 2nd Feb 2026, we have updated the kubelb-addons chart to v0.3.1 with dependency bumps and security fixes([#257](https://github.com/kubermatic/kubelb/pull/257)) and also release KubeLB v1.3.1 and v1.2.2 with the same security fixes. #### ingress-nginx 4.14.1 → 4.14.3 - [CVE-2026-1580](https://github.com/kubernetes/kubernetes/issues/136677) - auth-method nginx configuration injection - [CVE-2026-24512](https://github.com/kubernetes/kubernetes/issues/136678) - rules.http.paths.path nginx configuration injection - [CVE-2026-24513](https://github.com/kubernetes/kubernetes/issues/136679) - auth-url protection bypass - [CVE-2026-24514](https://github.com/kubernetes/kubernetes/issues/136680) - Admission Controller denial of service Reference: [[Security Advisory] Multiple issues in ingress-nginx](https://groups.google.com/a/kubernetes.io/g/dev/c/9RYJrB8e8ts/m/SCatUN2AAQAJ) #### envoy-gateway 1.6.2 → 1.6.3 - [CVE-2025-0913](https://nvd.nist.gov/vuln/detail/CVE-2025-0913) - Use-after-free in c-ares DNS resolver #### cert-manager v1.19.2 → v1.19.3 - [GHSA-gx3x-vq4p-mhhv](https://github.com/cert-manager/cert-manager/security/advisories/GHSA-gx3x-vq4p-mhhv) - DoS via malformed DNS response ## Get Started with KubeLB 1.3 Today - **Check out the release on** [GitHub](https://github.com/kubermatic/kubelb) and give us a star! ;) - **Read the docs**: Go through the detailed [release notes](https://docs.kubermatic.com/kubelb/v1.3/release-notes/) and [documentation](https://docs.kubermatic.com/kubelb/v1.3/) for specific configuration guides. We encourage all users to upgrade to v1.3 and explore the new capabilities that KubeLB has to offer. A huge thank you to our entire community, our customers, and the dedicated contributors who helped shape this incredible release. We can't wait to see what you build with KubeLB 1.3! --- ## Kubermatic SecureGuard - **URL:** https://www.kubermatic.com/products/kubermatic-secureguard/ - **Date:** 2026-03-30 - **Description:** Secure and automate secrets with Kubermatic SecureGuard, the open-source, Kubernetes-native secrets manager. # Kubermatic SecureGuard Secure and automate how your teams manage secrets without compromise [Get your free demo](/demo/) [Whitepaper](/whitepaper-kubermatic-secureguard/) [Solution Brief](/solution-brief-kubermatic-secureguard/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) **Automate secrets management with open-source transparency.** **Centrally manage your AI Tokens, database passwords and API keys - in your Cloud Native or traditional environment** ## Transparent and developer-first ### Without SecureGuard - Fragmented Secrets Management - Inconsistent Security Practices - Vendor Lock-In and Cost - Limited Automation and Integration - Compliance and Audit Gaps ### With SecureGuard - **Connect different secret providers** into one central home - **Reduce breach risk** through automation and identity-based access - **Lower costs** by using open-source, self-managed infrastructure - **Eliminate manual secret** rotation and synchronization - **Improve compliance** with centralized auditing and detailed access logs ## All you need to know about Kubermatic SecureGuard Kubermatic SecureGuard is a **self-hosted**, **open-source secrets management** solution that acts as a secure transport layer for secrets in cloud-native and traditional environments. KubeSG is the Kubernetes-native alternative to proprietary secrets managers. It combines the trusted security model of **OpenBao** with the automation power of the **External Secrets Operator** to enable a developer-friendly workflow. KubeSG enables automated, breakage-free secret rotation, delivering transparent, developer-friendly security for everything from infrastructure keys to AI tokens. [Get Your Free Solution Brief](/solution-brief-kubermatic-secureguard/) [Read the Blog Post](/blog/introducing-secureguard/) ![Safety Vault](/static/safety-vault_hu_9da241e5ab903711.png) ## Why Kubermatic SecureGuard? ![](/images/icons/visuals/item16.svg) ### OpenBao Core Secure backend with encryption in transit and at rest, fine-grained access controls, and full audit logs. ![](/static/icons/refresh-icon.svg) ### ESO Integration Synchronize secrets directly into Kubernetes clusters or between multiple external secret stores. ![](/static/icons/star-icon.svg) ### Native Kubernetes Secrets Support Developers use standard Secret objects. No app rewrites or SDKs needed. ![](/static/cycle-grad-icon.svg) ### Automated Synchronization & Rotation Secrets stay current and valid without downtime or manual updates. ![](/static/centralized-grad-icon.svg) ### Centralized Management One source of truth across all environments and clusters. ![](/static/struct-grad-icon.svg) ### Secret Distribution Deliver secrets securely to multi-cloud, edge, or disconnected environments. ![](/static/icons/scale-icon.svg) ### Extensible Authentication & Secret Engines Integrate easily with any identity provider or external system. ![](/static/icons/cert-icon.svg) ### Comprehensive Auditing Built-in visibility and compliance support for frameworks like SOC 2 and PCI-DSS. [Talk to an Expert](/demo/) > Stolen credentials are the #1 access vector in data breaches, accounting for 22% of all incidents. [Verizon](https://www.verizon.com/business/resources/Tea/reports/2025-dbir-data-breach-investigations-report.pdf) --- ## Another Growth Ring on the World Tree – Kubernetes v1.35 "Timbernetes" - **URL:** https://www.kubermatic.com/blog/another-growth-ring-on-the-world-tree-kubernetes-v1-35-timbernetes/ - **Date:** 2026-04-30 - **Description:** Discover the key features, improvements, and deprecations in Kubernetes v1.35 "Timbernetes" - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Joana Figueiredo Kubernetes continues to grow, release by release, and with v1.35, another strong growth ring is added to the project's ever-evolving "World Tree." Closing out 2025, Kubernetes v1.35 (codenamed **Timbernetes**) reflects the maturity, resilience, and steady innovation of the ecosystem. Inspired by Yggdrasil, the mythological world tree, this release highlights how Kubernetes is shaped by a global community that carefully prunes old APIs, strengthens core foundations, and introduces new capabilities to meet modern workload demands. Let's explore what's new. Kubernetes v1.35 includes **60 enhancements** in total, specifically: - 17 features graduating to Stable (GA) - 19 features promoted to Beta - 22 new Alpha features As always, the release also introduces important deprecations and removals that platform teams should review before upgrading. ## Highlights from project members In this blog post, we asked three of our engineers who are extensively involved in the Kubernetes project to share their key highlights. For a complete overview of all changes, we recommend checking out the official release announcement and the 1.35 changelog. > ***"The OCI image volume source is now enabled by default in Kubernetes 1.35 as it continues its path to graduation in upcoming releases, simplifying how teams manage data-intensive workloads like AI and machine learning. By allowing Pods to mount OCI artifacts and images directly as volumes, you can decouple machine learning models from your application code instead of baking them into a single, bloated runtime image. This significantly reduces image sizes and removes the need for the complex init containers or custom scripts previously required to fetch data at startup."***. > > — Marko Mudrinić is Tech Lead of SIG K8s Infra, a CNCF Ambassador, and Kubernetes Release Engineering Subproject Lead > ***"Kubernetes 1.35 just made life a lot easier with in-place Pod resource updates now hitting General Availability. You can finally tweak CPU and memory for your running Pods without a restart, which is huge not only for people running AI/MLOps workloads/batch jobs but also for anyone dealing with stateful apps (e.g., databases) that really don't like being interrupted. Before this, changing resources meant recreating Pods, which was error-prone and could mess up your workloads at the worst possible times."*** > > — Koray Oksay is a CNCF Ambassador, Kubeastronaut, and part of SIG K8s Infra > ***"The new Kubernetes Release is again a big win for everyone running AI or HPC jobs. introducing native gang scheduling that ensures your Pods launch together or not at all. This finally solves the headache of partial deployments, meaning you won't get stuck with deadlocked jobs that sit there wasting your cluster's expensive resources. It's a much-needed upgrade that makes orchestrating complex, heavy workloads way more efficient and reliable."*** > > — Mario Fahlandt is a Co-Chair of SIG ContribEx, also part of SIG K8s Infra, and a CNCF Ambassador ## Beyond these highlights, v1.35 offers other improvements, including ### Beta: Native Pod certificates for workload identity Kubernetes v1.35 introduces **native workload identity using Pod certificates**, significantly reducing the need for external controllers, sidecars, or custom CRDs. Key improvements include: - Certificates requested and issued by the kubelet - Automatic rotation handled natively - Certificates mounted directly into the Pod filesystem - No bearer tokens required in the issuance path This feature simplifies **mTLS**, **zero-trust architectures**, **and service mesh integrations**, while reducing operational complexity and security risks. It is tracked under **KEP-4317** and led by **SIG Auth**. ### Alpha: Node-declared features before scheduling To improve safety during upgrades and mixed-version environments, Kubernetes v1.35 introduces an **alpha framework for node-declared features**. Nodes can now explicitly report supported Kubernetes features through a new `.status.declaredFeatures` field. This allows: - Smarter scheduling decisions - Admission-time validation - Better handling of feature skew between control plane and nodes This work is part of **KEP-5328**, led by **SIG Node**. ## Deprecations and API removals Kubernetes v1.35 continues to prune legacy APIs and remove features no longer aligned with modern workloads. Key changes include: - **cgroup v1 removed**: Nodes must support cgroup v2. - **Ingress NGINX enters maintenance**: Transition to the Gateway API is recommended. - **kube-proxy `ipvs` mode deprecated**: `nftables` is the long-term replacement. - **API cleanups**: Several old beta/deprecated APIs have been removed. Platform teams are strongly encouraged to review the **[v1.35 changelog](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.35.md)**. ## Community The Kubernetes v1.35 release cycle spanned 14 weeks and included contributions from: - 419 individuals - 85 companies directly in Kubernetes - 1,700+ contributors across the broader cloud-native ecosystem This sustained velocity continues to reinforce Kubernetes as one of the most actively developed open source platforms in the world. ## Learn more - **[Official Kubernetes 1.35 release announcement](https://kubernetes.io/blog/2025/12/17/kubernetes-v1-35-release/)** - **[Kubernetes 1.35 changelog](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.35.md)** --- ## Kubermatic Joins the Agentic AI Foundation - **URL:** https://www.kubermatic.com/blog/kubermatic-joins-the-agentic-ai-foundation/ - **Date:** 2026-04-30 - **Description:** Kubermatic joins the Agentic AI Foundation to help shape open, agent-driven infrastructure and the future of autonomous Kubernetes operations. - **Categories:** Company, Community - **Tags:** Announcements, Open Source Projects - **Authors:** Sebastian Scheele We are thrilled to announce that Kubermatic has joined the newly formed **Agentic AI Foundation (AAIF)** as a founding Silver Member. Launched today under the Linux Foundation, the AAIF is dedicated to building a neutral, open ecosystem for the next generation of artificial intelligence: Agentic AI. By joining forces with industry leaders in this initiative, Kubermatic is doubling down on our commitment to open standards and the evolution of infrastructure automation. ## Why the Agentic AI Foundation? For years, Kubermatic has operated on a simple yet powerful premise: **Power through automation**. We believe that to manage the exploding complexity of cloud-native, edge, and multi-cloud environments, we must move beyond manual operations. However, the industry is now standing at a new threshold. We are transitioning from **automated** systems (which follow pre-defined scripts) to **agentic** systems (which can reason, plan, and act autonomously to solve problems). The AAIF provides the governance, neutrality, and shared infrastructure needed to ensure these powerful new agents are developed transparently and securely. As a company that has always championed open source (from [KubeOne](/products/kubermatic-kubeone/) to the [Kubermatic Kubernetes Platform](/products/kubermatic-kubernetes-platform/)), we believe the future of AI must be as open as the future of Kubernetes. ## The Game Changer: Model Context Protocol (MCP) A primary reason for our excitement about the AAIF is its support for the **[Model Context Protocol (MCP)](https://modelcontextprotocol.io/docs/getting-started/intro)**, one of the foundation's initial and most critical projects. For those unfamiliar, MCP is an open standard that acts as a universal translator between AI models and external systems. Until now, connecting an LLM to your infrastructure required building custom, brittle integrations for every single tool. **Here is why MCP is critical for the future of Kubernetes and Infrastructure Operations**: 1. **Standardized Context**: MCP allows us to expose the rich context of your infrastructure - cluster health, resource usage, logs, and network policies - to AI agents in a standardized format. The agent doesn't just "guess"; it reads the actual state of the world through a reliable protocol. 1. **From Chatbots to Operators**: With MCP, AI moves beyond being a passive chatbot that answers questions. It becomes an active operator. An MCP-enabled agent can securely query a Kubermatic cluster, identify a failing node, and, with proper permissions, execute the specific API calls to drain and replace that node. 1. **Breaking Down Silos**: In a multi-cloud environment, data is scattered across AWS, Azure, on-prem, and edge locations. MCP provides a unified way for agents to access this distributed context without us having to reinvent the wheel for every new AI model that hits the market. ## The Vision: AI-Native Infrastructure At Kubermatic, we see a future where Kubernetes platforms are not just managed by humans with scripts, but by intelligent agents that understand the intent behind the infrastructure. Imagine an environment where your platform doesn't just alert you to an error, but autonomously investigates the root cause using real-time data and drafts a remediation plan for your approval. This is the promise of Agentic AI. By joining the AAIF, we are ensuring that the standards enabling this future are built with the rigorous needs of enterprise infrastructure in mind: security, reliability, and scale. We look forward to collaborating with the Linux Foundation and our fellow members to build the open standard for the agentic web. *Learn more about the [Agentic AI Foundation](https://aaif.io/) at and explore the [Model Context Protocol](https://modelcontextprotocol.io/docs/getting-started/intro)*. --- ## Gartner® The Future of I&O 2030: The Impact of AI - **URL:** https://www.kubermatic.com/gartner-the-future-of-i-and-o-2030-the-impact-of-ai/ - **Date:** 2026-07-07 - **Description:** Discover the latest Gartner® report The Future of I&O 2030: The Impact of AI # “By 2029, 70% of enterprises will deploy agentic AI as a part of IT infrastructure operations, compared to less than 5% in 2025.” Gartner® The Future of I&O 2030: The Impact of AI ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Complimentary Gartner® ## The Future of I&O 2030: The Impact of AI Published 19 November 2025 [Download the Report](/gartner-the-future-of-i-and-o-2030-the-impact-of-ai/#report) ![Gartner® The Future of I&O 2030: The Impact of AI](/static/gartner-the-future-of-i-and-o-2030-the-impact-of-ai-img.png) **Is your I&O strategy ready for the age of Agentic AI?** The traditional I&O playbook is rapidly becoming obsolete. By 2030, the way you plan, build, and deliver infrastructure will be unrecognizable. *Gartner predicts that "by 2029, 70% of enterprises will deploy agentic AI within their infrastructure operations, a massive leap from less than 5% today."* Yet, only 6% of organizations currently have the maturity to handle this shift. Don’t let the gap widen between you and the competition. Download The Future of I&O 2030 to discover the six critical positions you must adopt to evolve from a steward of legacy systems to a leader of AI-defined infrastructure. **Are you prepared to lead this disruption, or will you risk being sidelined?** Discover **the strategic roadmap** you need to rewire your I&O culture for the age of Agentic AI. Download The Future of I&O 2030 today to explore in more detail the **six disruptive shifts** that will define the winners and losers of the coming AI revolution. If our form couldn't load correctly – This can have multiple reasons like ad blocker, not accepted cookies, JavaScript deactivated. However, you can still get in touch with us! Simply click on the button below, and you'll be able to submit the form and reach out to us for any inquiries or assistance you need. [Open form](https://share.hsforms.com/185NM2nciRzuLwxSfcCUEVw2piu8) * * * ***Gartner, The Future of I&O 2030: The Impact of AI, Joe Antelmi, Marissa Schmidt, Cameron Haight, Chirag Dekate, Ashish Banerjee, Andrew Lerner, 19 November 2025*** ***GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.*** ## Our Upcoming Events [![Proud partner of WeAreDevelopers World Congress Europe, 8-10 July, Berlin](/static/event-wearedevelopers26_hu_1cbbc2a6515d782.jpg)](https://www.wearedevelopers.com/) Onsite Conference ## [Join us in Berlin at WeAreDevelopers](https://www.wearedevelopers.com/) [Join Here](https://www.wearedevelopers.com/) [![](/static/containerdays-hamburg-2026_hu_d4a7201e201462bf.jpg)](https://www.containerdays.io/containerdays-hamburg-2026/) Onsite Conference ## [ContainerDays Hamburg is Back in the Harbor of Hamburg for 2026!](https://www.containerdays.io/containerdays-hamburg-2026/) [Join Here](https://www.containerdays.io/containerdays-hamburg-2026/) ## Ready to try Kubermatic Kubernetes Platform? [Get Your Free Demo](/demo/) --- ## The wait is over: Kubermatic Virtualization 1.0 is live - **URL:** https://www.kubermatic.com/blog/the-wait-is-over-kubermatic-virtualization-1-0-is-live/ - **Date:** 2026-04-30 - **Description:** The wait is over: Kubermatic Virtualization 1.0 is live! Experience cloud-native virtualization with HA, live migration, and enterprise-ready automation, powered by Kubernetes. - **Categories:** Company - **Tags:** KubeV, Announcements - **Authors:** Csenger Szabo For years, many organizations have relied on the public cloud to run their most critical workloads. But this approach has a serious drawback: it leaves companies vulnerable to sudden industry changes and geopolitical shifts. Amidst recent regulatory changes, companies are now worried about two major issues: [losing control over their data](/blog/is-europe-breaking-up-with-us-cloud-giants/) and getting trapped by **vendor lock-in**. The recent [Broadcom acquisition of VMware](/blog/why-your-virtualization-migration-is-just-the-beginning/) has highlighted this risk. IT teams are facing unpredictable prices and a loss of control over their infrastructure stack. Building [resilience](/blog/the-new-era-of-resilience-in-the-cloud/) is the key to ensuring that businesses keep running without any disruption, regardless of external changes. A private cloud is a strong building block of resilience. It gives teams the freedom to manage sensitive workloads on their own terms, giving them back data control and resilience, while balancing legacy VM workloads and modern containerized services. The Kubermatic team is proud to announce the general availability of **[Kubermatic Virtualization Business 1.0](https://www.kubermatic.com/products/kubermatic-virtualization/)**: the first production-ready version of our cloud-native virtualization platform. Kubermatic Virtualization is a complete platform for building and running a modern private cloud. It’s built on **Kubernetes** to manage both traditional Virtual Machines (VMs) and modern containers in one place. With Kubermatic Virtualization, you gain full control over your infrastructure and data, ensuring your services stay available regardless of what happens in the wider cloud industry. ## What’s inside Kubermatic Virtualization 1.0 [Kubermatic Virtualization](https://www.kubermatic.com/products/kubermatic-virtualization/) is an all-in-one platform for building and operating a modern private cloud, for both virtual machines and containers on your own hardware. Its core components include: - **[KubeOne](https://github.com/kubermatic/kubeone)**: Lifecycle management for Kubernetes clusters, from bare metal to tenant clusters. - **Kubermatic Virtualization**: The open-source virtualization layer for Kubernetes. - **KubeOVN**: Enterprise-grade SDN for Kubernetes. - **UI Console**: The intuitive dashboard for managing VMs end-to-end. ### Let’s explore the main features These are the key features that define Kubermatic Virtualization 1.0: - **High Availability (HA)**: The underlying Kubernetes platform automatically restarts failed VM or container workloads on a healthy host, significantly reducing downtime. - **Live VM Migration**: Move running virtual machines between physical hosts with zero downtime or interruption to users, enabling seamless hardware maintenance. - **Data Protection Ready**: Integrates easily with third-party backup and recovery solutions via Kubernetes-native APIs and hooks. - **Unified VM & Container Platform**: Run and manage virtual machines and containers side-by-side. - **Kubernetes-Native Management API**: Use a single, unified control plane for all infrastructure. - **Integrated Cloud-Native Networking (KubeOVN)**: A flat, high-performance L2/L3 network for all workloads. - **Automated Bare-Metal Cluster Provisioning (KubeOne)**: Simplify the deployment and lifecycle of the foundational platform. - **Centralized Management Console**: A single pane of glass for all operations. - **Provision Tenant Kubernetes Clusters**: Empower teams with a VM-based Kubernetes cluster (KubeOne). ### Introducing the enterprise-level installer: A powerful platform needs to be easy to set up. Kubermatic Virtualization 1.0 uses **KubeOne** for automated bare-metal cluster provisioning, turning complex deployment into a fast, repeatable process: - **Fast Environment Bootstrap**: Your entire virtualization environment (Kubernetes, networking, and virtualization layer) is ready to use in minutes. - **Preconfigured Storage and Load Balancing**: The installer automatically includes default storage and load balancing options, so you can immediately start creating and running workloads without manual configuration - **Simple Network Configuration**: Easily define your network settings during installation - no complex setup or manual steps required ## Why it matters Kubermatic Virtualization gives your organization independence and resilience in a changing cloud landscape. It’s a strategic advantage that helps teams: - Run containers and VMs together to cut hardware and energy costs - Perform hardware maintenance with zero downtime - Keep production workloads resilient and available - Manage everything with Kubernetes, not multiple dashboards Kubermatic Virtualization allows teams to build infrastructure that protects sensitive data, meets compliance requirements, and reduces reliance on public cloud providers. It’s a strategic advantage in an era of hybrid environments and geopolitical uncertainty. ## Get started today Kubermatic Virtualization 1.0 marks an important milestone in Kubermatic’s mission to make **cloud-native infrastructure accessible and open**. Whether you’re building a private cloud from scratch or modernizing your existing virtualization layer, Kubermatic Virtualization gives you the tools to run, protect, and scale your workloads on your terms. **Learn more and get started**: [visit the documentation](https://docs.kubermatic.com/kubermatic-virtualization/latest/) --- ## Meet KubeOne 1.12 - **URL:** https://www.kubermatic.com/blog/meet-kubeone-1-12-supporting-kubernetes-1-34/ - **Date:** 2026-04-30 - **Description:** The KubeOne 1.12 release introduces support for Kubernetes 1.34, CLI improvements, and new OS support for RHEL/Rocky Linux 9 and more. - **Categories:** Products - **Tags:** KubeOne - **Authors:** Artiom Diomin We are excited to announce the release of **KubeOne 1.12**! This release brings support for the latest Kubernetes version and several improvements to manage your clusters more flexibly. Here are the highlights of what's new in KubeOne 1.12. ## Complete support for Kubernetes 1.34 KubeOne 1.12 introduces full support for [Kubernetes 1.34](https://kubernetes.io/blog/2025/08/27/kubernetes-v1-34-release/). You can now provision new clusters or upgrade your existing ones to the latest stable Kubernetes version. - **RHEL 9 and Rockly Linux 9 Support**: We've validated the release against these OS versions, adding test scenarios for the newly supported RHEL and Rocky Linux 9.6 with Kubernetes 1.34. - **Addons & Images**: Internal addons and image lists have been refreshed to support 1.34 features out of the box. - **Comprehensive Updates**: We have updated all core components, including the **operating-system-manager** and **machine-controller**, to ensure seamless compatibility. ## Operational Enhancements & CLI Improvements We have added several flags and configuration options to give you more control over your cluster's lifecycle and maintenance. - **Cleaner Cluster Resets**: The `reset` command now includes flags to `--cleanup-volumes` and `--cleanup-load-balancers`. This is crucial for avoiding "orphaned" cloud resources that can accrue costs after a cluster is deleted. - **Cluster-Wide Kubelet Configuration**: You can now define a **Cluster-wide KubeletConfig**, simplifying the management of node configurations across your entire fleet without needing per-node tweaks. - **Configurable Timeouts**: The `machine-controller` join cluster timeout is now configurable, helping in environments where nodes might take longer to become ready. - **Improved Image Management**: The `config images list` command now supports an `--all` flag, allowing you to inspect all related images, not just the ones actively used in your current config. ## Improved security & Customization APIs KubeOne 1.12 opens up new APIs for deeper customization of your cluster security and container runtime. - **Certificate Validity**: New API fields `certificateValidityPeriod` and `caCertificateValidityPeriod` have been added, allowing administrators to define custom expiration policies for cluster certificates. - **Bastion SSH Key**: You can now explicitly configure the bastion SSH private key file in the host config, decoupling it from the Terraform output. - **Containerd Mirrors**: A new `overridePath` API allows you to configure the `override_path` mirrors parameter for containerd, useful for air-gapped or optimized registry setups. - **Non-Root Devices**: Added an option to enable non-root device usage in worker nodes via the Operating System Manager. ## Other Provider & Component Updates - **Nutanix**: Upgraded the CSI driver to v3.3.4. - **Azure**: Switched to `flatcar-container-linux-corevm-amd64` for Flatcar deployments on Azure. - **OpenStack**: Updated Cloud Controller Manager (CCM) and CSI to version 1.34.0. - **Cluster Autoscaler**: The addon has been refreshed to align with upstream changes. We hope [KubeOne 1.12](https://github.com/kubermatic/kubeone) helps you manage your Kubernetes clusters with greater ease! For more details, check out the [changelog](https://github.com/kubermatic/kubeone/tree/main/CHANGELOG) and upgrade instructions. As always, we'd love to hear your feedback. Reach out to us on our {{< slackjoinlink "Community Slack" >}} or on [GitHub](https://github.com/kubermatic/kubeone)! --- ## The "Wild West" of AI Infra is Over. Kubermatic is officially Kubernetes AI Conformant - **URL:** https://www.kubermatic.com/blog/kubermatic-is-officially-kubernetes-ai-conformant/ - **Date:** 2026-04-30 - **Description:** It's official: The new global standard for AI on Kubernetes is here. - **Categories:** Products, Community - **Tags:** KKP, Open Source Projects - **Authors:** Mario Fahlandt For years, building AI infrastructure felt like the "Wild West", with all the fragmented tools, proprietary stacks, and exploding costs. Today, that changes. At KubeCon North America, the [Cloud Native Computing Foundation (CNCF)](https://www.cncf.io/) officially launched the Kubernetes AI Conformance program. It is now the new global technical standard for how AI runs on Kubernetes. We are incredibly proud to announce that Kubermatic is one of the very first platforms globally, and among the first in Europe, to be officially Kubernetes AI Conformant for Kubernetes v1.34. ## What "AI Conformance" actually means While ISO standards like ISO 42001 focus on management and governance, Kubernetes AI Conformance is purely technical. It defines the APIs, capabilities, and configurations a Kubernetes cluster must support to run AI/ML workloads efficiently and securely. In short: If a platform is "AI Conformant," you can train and deploy models on it, and move them to another conformant cluster without rewriting anything. This means freedom from vendor lock-in and a clear path toward portable, sovereign, AI Infrastructure. ## Kubermatic's journey to becoming Kubernetes AI Conformant To define the standard for "Kubernetes AI Conformance", a dedicated "Working Group" was formed within the Kubernetes project, sponsored by the Architecture and Testing Special Interest Groups (SIGs). Kubermatic is proud to be an active member. Since KubeCon Europe in London, the Working Group has worked intensively to identify the core technical pillars needed to address the unique challenges of AI workloads. The outcome of this effort was a requirements catalog that every platform must meet to be considered Kubernetes AI Conformant. Kubermatic already had most of the foundational pieces, but the conformance process pushed us to validate, document, and harden them to production-grade levels. [Kubermatic KKP 2.29](/blog/meet-kkp-2-29-the-next-step-in-making-kubernetes-ai-ready/) delivers on every one of these mandatory requirements. Here's how Kubermatic implemented each requirement to achieve full AI Conformance: ### 1. Efficient Accelerator Management for AI Training In non-standard environments, this leads to severe "resource fragmentation," where large parts of valuable GPU memory remain unused, and "topology blindness," where scheduling is not optimized for multi-GPU workloads. This results in massive over-provisioning and exploding costs. KKP 2.29 implements this today. DRA, stable since Kubernetes 1.34, provides a flexible new way to request and share complex hardware resources. Functioning much like the familiar `PersistentVolumeClaim` model for storage, DRA allows users to "claim" the exact resources they need from defined "classes" of devices, while Kubernetes handles all the complex scheduling and node placement automatically. [Learn how to employ DRA in KKP](https://docs.kubermatic.com/kubermatic/v2.29/tutorials-howtos/dynamic-resource-allocation/). ### 2. Advanced Ingress for AI Inference AI inference workloads (the models in production) are fundamentally different from traditional, stateless web applications. They are often long-running, resource-intensive, and partially stateful, making them a poor fit for standard load balancers. KKP delivers this through the [KubeLB 1.2 AI Gateway](https://docs.kubermatic.com/kubermatic/v2.29/tutorials-howtos/networking/ai-inference-routing/). This feature integrates the open-source Kgateway and its powerful inference extension, providing optimized routing and load balancing specifically for AI workloads. Its capabilities include weighted traffic splitting and header-based routing, which is important for OpenAI protocol headers. ### 3. Scheduling & Orchestration Distributed AI training jobs often require multiple components (Pods) to be started simultaneously. A traditional scheduler that places Pods one by one can lead to "deadlocks," where a job gets stuck because not all of its parts can find resources, all while blocking the resources it has already been assigned. KKP 2.29 includes [Kueue job scheduler](https://docs.kubermatic.com/kubermatic/v2.29/architecture/concept/kkp-concepts/applications/default-applications-catalog/kueue/) in its default application catalog, ensuring that distributed AI workloads are scheduled efficiently. Furthermore, KKP meets the autoscaling requirements, providing a fully functional [Cluster Autoscaler](https://docs.kubermatic.com/kubermatic/v2.29/tutorials-howtos/kkp-autoscaler/cluster-autoscaler/) capable of scaling accelerator node groups and support for the [HorizontalPodAutoscaler (HPA) with custom GPU metrics](https://docs.kubermatic.com/kubermatic/v2.29/tutorials-howtos/hpa-with-custom-gpu-metrics/). ### 4. Monitoring and Metrics The new generation of AI workloads and specialized hardware creates a "blind spot" in monitoring. There is "currently no standard way to collect accelerator metrics," and operators lack the tools to quickly debug complex AI infrastructure problems. KKP's robust, [built-in monitoring stack](https://docs.kubermatic.com/kubermatic/v2.29/architecture/monitoring-logging-alerting/user-cluster/) for user clusters fulfills these requirements. It enables the collection of detailed performance metrics from supported accelerator types (e.g., utilization, memory) via a standardized endpoint. It also provides a monitoring system capable of discovering and collecting metrics from any workload that exposes them in a standard format (e.g., Prometheus exposition format). ### 5. Security and Resource Separation Expensive accelerators (GPUs) are a shared resource. Without strict isolation at the kernel and API levels, workloads in one container could access or interfere with the data or processes of workloads in another, posing a significant security risk in multi-tenant environments. Access to accelerators must be properly isolated and mediated via Kubernetes resource management frameworks (like DRA or device plugins). KKP's implementation of these frameworks ensures that access from within containers is properly isolated, preventing unauthorized access or interference between workloads, a core requirement for secure, multi-tenant AI platforms. ### 6. Robust Operator Support Modern AI frameworks like Ray or Kubeflow are themselves complex, distributed systems that run as "Operators" on Kubernetes. If the core platform (e.g., its webhooks, CRD management, or API server stability) is not robust, these operators will fail, rendering the entire AI platform useless. KKP 2.29 is proven to do this, with full support for reliably installing and running complex add-ons, including [Kubeflow](https://docs.kubermatic.com/kubermatic/v2.29/architecture/concept/kkp-concepts/addons/kubeflow/). This includes verifying that the operator's pods, webhooks, and custom resource reconciliation function correctly. ## KKP 2.29 is a Kubernetes AI Conformant Platform After completing the conformance checklist and submitting our results, Kubermatic officially passed all validation criteria for Kubernetes 1.34. You can see our certification record here: [Kubermatic AI Conformance on GitHub](https://github.com/cncf/ai-conformance/blob/main/v1.34/kubermatic/PRODUCT.yaml). ## Why This Matters for the Future of AI in Europe For European enterprises, this is about digital sovereignty. With an open, community-driven standard backed by the CNCF, organizations can finally deploy AI workloads anywhere: public cloud, private data center, or edge, without sacrificing compliance or control. As our CEO, [Sebastian Scheele](https://www.linkedin.com/in/sebastian-scheele/), puts it: > ***The future of AI will be built on open standards, not walled gardens. This conformance program is the foundation for that future, ensuring a level playing field where innovation and portability win***. We are ready to help you build that future today. ## Learn More - [CNCF AI Conformance Program](https://github.com/cncf/ai-conformance) - [Working Group: AI Conformance](https://github.com/kubernetes-sigs/wg-ai-conformance) - [KKP 2.29 AI Kit Highlights](https://docs.kubermatic.com/kubermatic/v2.29/architecture/concept/kkp-concepts/applications/default-applications-catalog/aikit/) --- ## Exploring cluster management utilities: essential tools and strategies - **URL:** https://www.kubermatic.com/blog/exploring-cluster-management-utilities-essential-tools-and-strategies/ - **Date:** 2026-04-30 - **Description:** In this blog, we'll explore key cluster management utilities and tools to automate and facilitate cluster management tasks, tailored for software architects. - **Categories:** Community - **Tags:** Open Source Projects In recent years, the rise of Kubernetes clusters has introduced a new set of challenges for software architects. With an ever-increasing number of clusters and workloads, managing them has become a tricky task. ## Definition and Importance of Cluster Management Cluster management involves the essential tasks related to orchestrating and administering multiple clusters. It includes monitoring the health of cluster nodes, efficiently allocating and scheduling resources, and maintaining smooth and reliable operational flows. For software architects, finding and using the right tools to help and automate cluster management is crucial. The right tool selection can mean the difference between enjoying seamless operations and scalability or dealing with system bottlenecks, especially in high-demand settings. In this blog, we’ll explore key cluster management utilities and tools that can make your life easier when managing clusters. ## Categories of Cluster Management Utilities To better explore cluster management utilities, it's important to first understand the categories of tools available. We can divide them into two main sets: ### 1. Tools to Manage and Observe Workloads in Clusters These open-source tools help you manage and monitor the activities happening inside your clusters: **K9s** <img src="/static/k9s.gif" alt="" width="800" height="505" loading="lazy" style="display:block;height:auto;margin:20px auto;"> [K9s](https://k9scli.io/) acts as an extension of the Kubernetes Command Line Interface (CLI). It’s a terminal-based interface that allows you to navigate your Kubernetes clusters faster. Essentially, it provides all the functionalities of kubectl, but in a more streamlined and faster manner. **K8sGPT** <img src="/static/k8tsgpt.gif" alt="" width="800" height="505" loading="lazy" style="display:block;height:auto;margin:20px auto;"> [K8sGPT](https://k8sgpt.ai/) leverages AI to give you a clearer view of your Kubernetes cluster. It scans your cluster to diagnose issues and presents explanations in plain English, making troubleshooting more accessible. It integrates smoothly with various AI backends while respecting privacy with local data processing. Discover more details about how K8sGPT makes debugging Kubernetes clusters easier in [this article](/blog/troubleshooting-with-ai-how-k8sgpt-makes-debugging-kubernetes-clusters-easier/). **Fubectl** <img src="/static/fubectl.gif" alt="" width="800" height="505" loading="lazy" style="display:block;height:auto;margin:20px auto;"> Created by Kubernetes enthusiasts, [Fubectl](https://github.com/kubermatic/fubectl) builds on kubectl to provide faster access to nodes and pods. It doesn’t rely on commercial platforms but offers great benefits, especially for [Kubermatic](/) users. ### 2. Tools to Create and Manage Clusters Beyond managing existing workloads, these tools assist in setting up and managing clusters: **Karpenter** [Karpenter](https://karpenter.sh/) is designed to simplify Kubernetes infrastructure. It helps with auto-scaling and provisioning additional compute resources, focusing on cost optimization, and application availability. **Helm** [Helm](https://helm.sh/) is a package manager for Kubernetes. It allows you to easily install and upgrade applications defined by charts inside your cluster. It's a [CNCF](https://contribute.cncf.io/contributors/projects/#helm) open-source project that’s fully supported by the community. **KubeOne** [KubeOne](https://github.com/kubermatic/kubeone) automates cluster operations on all your cloud, on-prem, edge, and IoT environments. It provides you with full lifecycle management of your clusters, including provisioning, upgrading, and repairing them whenever necessary. It is maintained by [Kubermatic](/). ## Suites Integrating Multiple Tools While individual tools are beneficial, some solutions offer integrated suites combining several tools into a cohesive package. The [Kubermatic Kubernetes Platform](/products/kubermatic-kubernetes-platform/) (KKP) is a great example of such a suite. KKP simplifies cluster management by incorporating tools like K8sGPT for diagnosing and simplifying cluster issues through AI, and Karpenter for efficient autoscaling and resource management. It also enables seamless application management with tools like Helm, automating much of the manual labor involved in maintaining complex Kubernetes environments. Discover more about [KKP](/products/kubermatic-kubernetes-platform/) or [book a demo](/demo/) to see it in action. --- ## A Platform Engineer's Guide to Confidential Containers - **URL:** https://www.kubermatic.com/blog/a-platform-engineers-guide-to-confidential-containers/ - **Date:** 2026-04-30 - **Description:** A Platform Engineer's Guide to Confidential Containers - **Categories:** Community - **Tags:** Open Source Projects - **Authors:** Akash Gautam As organizations increasingly rely on cloud infrastructure and shared environments, securing data when it is being processed has become a major security concern. The [Confidential Containers](https://confidentialcontainers.org/docs/overview/) (CoCo) project addresses this challenge by offering a hardware-enforced security layer that Platform Engineers can automate, simplifying security compliance for developers and reducing the operational burden on SRE teams. ## Why We Need to Protect Data-in-Use Data security is traditionally approached by focusing on two states: **data at rest** (long-term storage) and **data in transit** (network movement). We have mature, often out-of-the-box, solutions for these states, such as TLS for transit and storage encryption for rest. However, the third state—**data in use**— is often overlooked. At runtime, the application as well as the data processed by it is loaded in the memory on infrastructure which may not be owned by the user (like rented cloud servers). The core threat that confidential computing attempts to neutralize is the memory dump. A malicious or compromised cloud administrator who has access to the device can take a memory dump of the processing application, potentially viewing sensitive data in plaintext, leading to a data breach. The primary goal of Confidential Computing is to ensure the confidentiality and integrity of data, specifically when it is being processed. ## Hardware-Level Isolation with TEEs Confidential Computing relies on specialized processor technology to solve this problem. The core technology is the **Trusted Execution Environment (TEE)**. A TEE can be viewed as a "safe space" or "encrypted vault" within the main processor designed to run code and process data in isolation from the rest of the system. The key feature of the TEE is **encrypted memory**. Even if a compromised administrator successfully executes a memory dump of the application, they will only see encrypted gibberish, not the actual plaintext data. The application running inside the TEE, however, can process and view the unencrypted data. While early TEE offerings were process-based, modern TEEs are often available at the **VM level**. VM-based TEEs are more popular because it is easier to lift-and-shift applications across different infrastructure providers. ### Attestation: Establishing Cryptographic Trust TEEs are not blindly trusted; they are **attestable**. When a TEE is created, the hardware vendor provides an attestation report that contains an initial measurement of the hardware. Application owners must take this report and attest it against an **Attestation Service**. This provides a cryptographic guarantee that the TEE has not been tampered with. Sensitive code or data is only released into the TEE once this verification passes. ## Introducing the Confidential Containers (CoCo) Project [Confidential Containers](https://confidentialcontainers.org/docs/overview/) (CoCo) is a CNCF project providing the necessary software stack to run confidential workloads effectively on Kubernetes. The central approach of CoCo is to encapsulate each Kubernetes Pod inside its own Trusted Execution Environment. This drastically limits the scope of trust required for the workload. For developers, running a confidential workload requires minimal changes to the existing Kubernetes workflow. The only change needed is specifying the appropriate `runtimeClassName` in the deployment or pod definition. ### How it Works Under the Hood The [CoCo components](https://confidentialcontainers.org/docs/architecture/design-overview/#components) handle the heavy lifting: 1. **The CoCo Operator**: The Confidential Container Operator (CC operator) reads a custom resource (`CC runtime`) and is responsible for making specific runtime classes available based on the underlying hardware. It manages the configuration at the container runtime level (e.g., ContainerD), downloading binaries like the kata shim and updating container runtime configurations. 2. **Kata and MicroVMs**: CoCo leverages [Kata](https://katacontainers.io/), an open-source project that runs pods inside **microVMs**—stripped-down, barebone VMs optimized for containers. In the case of CoCo, the microVM is virtualized from hardware that supports confidential computing, effectively placing the entire pod inside a TEE. Inside the TEE, essential guest components are deployed, including the Kata Agent (managing the workload), the Attestation Agent (for verification), and the **Confidential Data Hub (CDH)** (for key and secret management). ### Using Public Cloud with The Peer Pod Approach A common challenge for Platform Engineers is deploying TEEs in public cloud environments where the Kubernetes worker nodes themselves are standard VMs without direct confidential computing support. CoCo solves this using the **Peer Pod** or [Cloud API Adaptor](https://github.com/confidential-containers/cloud-api-adaptor) approach. In this model, the virtualization layer of the node is replaced by the cloud provider. Instead of the Kata runtime talking to a local hypervisor on the worker node, it communicates with a [Cloud API Adaptor](https://github.com/confidential-containers/cloud-api-adaptor) (provided by CoCo). The Adaptor then provisions the confidential microVM using the cloud provider's TEE-enabled hardware (e.g., [AWS EC2 M6A](https://aws.amazon.com/ec2/instance-types/m6a/) instances powered by AMD's [SEV-SNP](https://www.amd.com/en/developer/sev.html)). The rest of the workflow—including attestation and interactions with KBS—remains the same. ## Lazy Attestation and Key Management For SREs and security specialists, understanding the workflow for secret retrieval is critical, as it confirms that no data is ever processed without verification. CoCo utilizes *lazy attestation*, meaning the attestation process is only triggered when a secret (such as an encrypted container image key, credentials of a database from where sensitive data will be read for processing etc) is actually needed. Here is the essential workflow: 1. **Secret Request**: The Kata agent or the application requests a secret via the Confidential Data Hub (CDH), which is running inside the guest TEE. 2. **Attestation Trigger**: The CDH notifies the Attestation Agent to fire the attestation request. 3. **Report Submission**: The Attestation Agent sends the TEE's attestation report to the Key Broker Service (KBS). The location of the KBS is provided via initialization data in the pod annotation. 4. **Verification**: The KBS sends the report to an Attestation Service to confirm that the TEE is genuine and untampered ("verification check passed"). 5. **Key Release**: Only upon successful verification does the KBS release the encryption key back to the application or agent inside the TEE. This process ensures that sensitive data is only released to attested secure environments. ## Reduced Trusted Compute Base (TCB) For Enterprise Architects and SREs, the primary security benefit of Confidential Containers is the drastic reduction of the *Trusted Compute Base (TCB)*. The TCB is defined as the entire set of hardware, software, and firmware components that an application must implicitly trust. In a traditional Kubernetes deployment, the TCB is high; the application trusts the worker node's Host OS, kernel, Containerd, kubelet, and various host components from different vendors. If any of these components are compromised, the application can be compromised. With CoCo, the application no longer trusts the worker node on which it is running. The TCB is reduced to the specialized hardware providing the TEE and the minimal software components running *inside* that TEE (like the CDH and Kata agent). Even the container image is pulled directly inside the trusted execution environment, not on the untrusted node. This shift places the root of trust primarily on the hardware itself, which is significantly harder to compromise than software. ### Operational Considerations While offering immense security benefits, Platform Engineers should note two key performance impacts: 1. Startup time increases because the microVM must be provisioned and launched before the pod can start running. 2. Impact on network performance varies depending upon the environment, but usually, overhead is less than 10% in most cases. ## Conclusion: Scaling Security, Not Your Team Confidential Containers are essential for organizations dealing with highly sensitive data or strict regulatory requirements, such as DORA (Digital Operational Resiliency Act) compliance for financial entities requiring protection of data in use, or protecting proprietary data used in modern AI/ML workloads. By implementing and automating the CoCo stack, the platform team provides an incredibly powerful, hardware-enforced security guarantee as a simple, self-service option (a mere `runtimeClassName`) for developers. You are automating security and compliance at the highest level, enabling developers to innovate rapidly without ever compromising on the integrity and confidentiality of processing data. You can deploy confidential workloads on the Cloud provider of your choice using the [Kubermatic Kubernetes Platform (KKP)](/products/kubermatic-kubernetes-platform/). You can learn more about Confidential Containers from my talk at the Container Days 2025 conference in Hamburg, where I showed confidential containers in action. {{< youtube "https://www.youtube.com/embed/pqc_lSXgPZk" >}} --- ## Inside CID's Cloud Transformation with Kubermatic - **URL:** https://www.kubermatic.com/customers/cid/ - **Date:** 2026-06-23 - **Description:** At CDS25, CID GmbH shares how they leverage the Kubermatic Kubernetes Platform (KKP) to automate, scale, and simplify operations — enabling faster innovation and cloud-native transformation. # Accelerating Cloud-Native Transformation with Kubermatic ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Customer Success Story ## Inside CID's Cloud Transformation with Kubermatic At CDS25, Rouven Loerch, General Manager at CID GmbH, shares how CID is leveraging the Kubermatic Kubernetes Platform (KKP) together with KubeLB to modernize infrastructure, simplify cluster operations, and enhance scalability across their cloud-native environments. CID adopted Kubermatic to unify Kubernetes management, reduce operational complexity, and improve reliability across development and production systems. By integrating KubeLB, Kubermatic’s lightweight and cloud-agnostic load balancer, CID solved one of the most common challenges in Kubernetes environments, ensuring consistent, high-performance load balancing across clusters and infrastructures. With KKP and KubeLB working together, CID can now deliver faster, more resilient services to its customers while empowering teams to focus more on innovation and less on manual infrastructure maintenance. **Key takeaways**: - CID automates and standardizes cluster management with KKP - KubeLB simplifies and unifies load balancing across environments - Improving performance and reducing infrastructure downtime - Enabling development teams to focus on value creation instead of operations **About the Speaker** Rouven Loerch is the General Manager at CID GmbH, where he drives the company’s technology strategy and cloud transformation initiatives. With deep expertise in IT infrastructure and business operations, Rouven oversees CID’s transition toward a scalable, cloud-native architecture powered by Kubernetes and open-source innovation. > People \[at Kubermatic] are very motivated, very passionate, and very invested in the project. They are looking for the best result for the customer, and that is not standard in IT. That's what we really liked in working with Kubermatic. Rouven Loerch, General Manager at CID GmbH --- ## From Compliance to Innovation: How Charité Uses Kubermatic to Transform IT - **URL:** https://www.kubermatic.com/customers/charite/ - **Date:** 2026-06-23 - **Description:** At CDS25, Charité – Universitätsmedizin Berlin shares how they automate and scale Kubernetes environments using Kubermatic Kubernetes Platform (KKP) to drive digital transformation in healthcare. # Transforming Healthcare IT with Kubernetes Automation ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Customer Success Story ## From Compliance to Innovation: How Charité Uses Kubermatic to Transform IT At CDS25, Harald Wagener, Group Leader for Cloud and IT Infrastructure at the Berlin Institute for Health Research at Charité, shares how the hospital leverages the Kubermatic Kubernetes Platform (KKP) to automate multi-cluster operations, strengthen compliance, and accelerate innovation across one of Europe’s largest university hospitals. With Kubernetes automation, Charité streamlines daily operations, reduces manual workload for platform teams, and ensures consistent governance across all environments from development to production. KKP helps standardize cluster lifecycle management, enforce policy at scale, and enable developers to focus on innovation. **Key takeaways**: - How automation reduces operational overhead in complex environments - Why KKP simplifies multi-cluster management and governance - Staying compliant with strict healthcare regulations while moving faster - The role of open-source collaboration in digital transformation **About the Speaker** Harald Wagener is the Group Leader for Cloud and IT Infrastructure at the Berlin Institute for Health Research at Charité. He leads the institute’s efforts to build scalable, secure, and automated infrastructure for biomedical data management and research. With extensive expertise in DevOps and cloud architecture, Harald plays a key role in advancing Charité’s digital transformation through open-source technologies and Kubernetes. > Kubermatic not only helped us with the implementation of the authentication system but also with very specific requirements... Harald Wagener, Group Leader for Cloud and IT Infrastructure, Berlin Institute for Health Research at Charité --- ## Meet KKP 2.29: The next step in making Kubernetes AI-ready - **URL:** https://www.kubermatic.com/blog/meet-kkp-2-29-the-next-step-in-making-kubernetes-ai-ready/ - **Date:** 2026-04-30 - **Description:** Discover what's new in KKP 2.29: Making Kubernetes AI-ready, OpenStack integration, and improved security. - **Categories:** Products - **Tags:** KKP - **Authors:** Csenger Szabo We're thrilled to announce the release of Kubermatic Kubernetes Platform (KKP) 2.29! This release focuses on empowering AI/ML workloads, expanding OpenStack capabilities, strengthening security, and updating lifecycle and platform support. Let's explore what's new: ## Powering the next wave of AI applications With the rise of AI, providing robust support for GPU-accelerated workloads is a top priority. KKP 2.29 introduces several features to streamline the management and operation of AI/ML applications. - **Dynamic Resource Allocation (DRA) Enabled**: The necessary feature gates for Dynamic Resource Allocation (DRA) have been enabled across required components, paving the way for more sophisticated third-party resource management. - **Kueue for Batch Processing**: The Kueue job scheduler has been added to the default application catalog, providing powerful job queueing and resource management capabilities for batch and AI/ML workloads. - **Enhanced GPU Visibility**: The dashboard now parses and displays NVIDIA GPU Operator-related labels on nodes, giving you immediate insight into your GPU resources. We also now expose driver versions in the NVIDIA GPU operator and have enabled default GPU metrics collection. ## Upgrading the Application Catalog We are initiating a strategic revamp of the Application Catalog to enhance its maintainability, scalability, and independence from the main KKP release schedule. The new architecture will feature a dedicated controller that pulls application manifests from an OCI registry. This change will allow for more frequent application updates, detached from the platform release cycle, and will also empower users to define their own custom OCI registries - a critical feature for air-gapped or restricted environments. ## Evolving cloud provider management This release brings several improvements for cloud providers, with a special focus on OpenStack, while also formally deprecating the Equinix Metal provider. ## OpenStack gets a boost - **Configurable LoadBalancer Classes**: You can now set LoadBalancer Classes directly on the cluster spec for OpenStack environments, with a corresponding endpoint added to the dashboard. - **Custom Subnet CIDRs**: KKP 2.29 provides the flexibility to set custom IPv4 and IPv6 CIDRs for OpenStack subnets. - **Skip Router Reconciliation**: A new option allows you to skip router reconciliation for OpenStack clusters, providing more control over your networking topology. - **Config Drive Support**: You can now enable config drive for OpenStack, improving metadata handling for instances. ## Deprecations Support for the Equinix Metal provider has been officially removed from KKP. ## Hardened security and simplified administration KKP 2.29 introduces several new features to improve security and control for administrators: - **Editable Encryption at Rest**: You can now enable or disable the "Encryption at Rest" feature on a running user cluster from the dashboard. KKP will also now clean up encryption secrets when a cluster is deleted or the feature is disabled. - **Restrict Project Modification**: A new setting has been added to restrict project modifications to project administrators, preventing non-admin members from making changes. - **Extended Authorization Webhooks**: The configuration for authorization webhooks in user clusters has been extended, including support for egress network policies. - **Safe Preset Deletion**: The admin interface now provides linkage information for presets, helping prevent the accidental deletion of presets that are currently in use. ## Updated lifecycle and platform support - **Kubernetes 1.34 Support**: Stay up-to-date with the latest from the community with added support for [Kubernetes version 1.34](https://kubernetes.io/blog/2025/08/27/kubernetes-v1-34-release/). - **Expanded OS Support**: We have officially added support for [Rocky Linux 9](https://rockylinux.org/news/rocky-linux-9-0-ga-release) and RHEL 9 as user cluster operating systems. - **Cilium Upgrade**: [Cilium](https://github.com/cilium/cilium) has been upgraded to versions 1.17.7 and 1.18.1. - **Gateway API Installation with KubeLB**: When using [KubeLB](/products/kubelb/), KKP now automatically installs the Kubernetes Gateway APIs. - **Cluster-Level Registry Mirrors**: You can now configure container registry mirrors at the cluster level, providing more flexibility for air-gapped or restricted environments. ## A better dashboard experience - **Simplified Cluster Autoscaler Configuration**: The configuration for the Cluster Autoscaler has been conveniently moved into the "Initial Nodes" step in the cluster creation wizard. - **A More Powerful Web Terminal**: The web terminal image is now equipped with **k9s**, **krew**, and **oidc-login**, giving you more tools right out of the box. - **Native kubectl OIDC Login Support**: KKP now supports the **kubelogin** kubectl plugin, simplifying authentication workflows. - **Enhanced Node Visibility**: The dashboard will now display labels for each node in the node list, offering more at-a-glance information. ## Have a good time trying out the new features! We hope you find these new features and improvements valuable for your projects! Thank you for being a part of the Kubermatic community, and we look forward to your feedback on KKP 2.29. If you find our contributions valuable, we kindly encourage you to leave a star on our [GitHub repository](https://github.com/kubermatic/kubermatic). As always, please don't hesitate to reach out with any questions or suggestions via [Contact Us](/contact-us/#ask-anything) form. --- ## Decoding 2025 Hype Cycle - **URL:** https://www.kubermatic.com/blog/decoding-2025-hype-cycle/ - **Date:** 2026-04-30 - **Description:** Gartner's Hype Cycle for Infrastructure Strategy is with us. Here, we explore four Solutions enabled by Cloud Native and Kubernetes for your Platforms. - **Categories:** Community - **Tags:** Open Source Projects - **Authors:** Anthony Hodson Gartner's Hype Cycle for Infrastructure Strategy is with us. Here, we explore four Solutions enabled by Cloud Native and Kubernetes for your Platforms. ## Introduction **IT leaders**, **architects**, including **CTOs**, **VPs of Infrastructure**, and **Heads of Enterprise Architecture**, are navigating the options for modernizing their technology stacks. Their decisions are operated by **Site Reliability Engineers (SREs)** and **Platform Engineering Leads** who are on the front lines of implementation. Even those who are "Cloud Native Curious" with infrastructure backgrounds will see changes approaching with Visualisation's move within Cloud-Native environments. Gartner's Hype Cycle shows themes and trends that are moving from 'novel' to 'normal'. It provides a critical lens for navigating the rollercoaster of emerging technologies, how certain we are of their value, and how wide-spread their adoption is. While some see it as a mere discussion point, its value lies in providing a framework for intentional and strategic investment. Technologies that successfully traverse the cycle often become commoditized, shifting the focus from a specific vendor to a universal category, a trend fueled by open-source solutions. The question for every leader is how to manage the inherent risk and reward of new vs proven. Technologies in the early stages of the cycle offer the potential for a significant competitive advantage, but require a **culture of experimentation** and a **tolerance for failure**. As they mature, benefits become well-understood, tools evolve and good practice emerges. This approach to technology adoption is not just about staying competitive; it's a powerful tool for **talent retention and innovation**. A culture that encourages **experimentation** and provides modern tooling empowers employees, giving them a sense of purpose and ownership. > ***Research shows that employees who are highly engaged and see opportunities for professional growth are far more likely to stay with a company. According to Gallup, businesses with highly engaged workforces see significantly ([51%](https://www.gallup.com/q12-employee-engagement-survey/)) lower turnover (Q7 & Q12).*** By embracing new technologies, you signal a commitment to innovation that can reduce churn and attract top talent. This, in turn, creates a self-reinforcing [flywheel](https://www.youtube.com/watch?v=dZXlVTYd_e8) for success, as a motivated workforce is more likely to develop the groundbreaking ideas that can drive your business forward. **A word on Solutions**: _Several of the routes forward offered below are ones which Kubermatic can facilitate, naturally, having developed solutions for these affords us an expertise in these spaces. As with everything in the HypeCycle, being outcome based not vendor specific gives a more complete view of the landscape. Gartner do have write-ups of the participants in these markets of which Kubermatic is happy to often be featured in [Kubermatic Named in Gartner® Magic Quadrant™ for Container Management](/blog/kubermatic-named-in-gartner-magic-quadrant-for-container-management/)_ ## 1. The Unification Project: Bringing Legacy VMs into the Kubernetes Ecosystem For years, many organizations, especially those outside the tech industry, have relied on **virtual machines (VMs)** as the bedrock of their infrastructure. While this approach has been reliable, the landscape is now shifting dramatically. Infrastructure teams are facing unprecedented **price hikes** for their VMware estates, with some reports citing increases of up to [1,050%](https://www.theregister.com/2024/10/01/att_broadcom_filings_update/) from Broadcom VMware's new owner. This has prompted major players like AT&T to consider a costly, multi-year migration project, a decision many other companies now face. Meanwhile, the cloud-native ecosystem continues to mature. Kubernetes adoption is surging, driven by a [24% year-on-year growth rate](https://www.skyquestt.com/report/kubernetes-market) and its emergence as mission-critical infrastructure. While a staggering [92% of IT-centric organizations use containers](https://www.docker.com/blog/2025-docker-state-of-app-dev/), the adoption rate drops to just 30% in other sectors. This gap creates a challenge: how do you modernize without a full-scale, disruptive migration? This is where the **Unification Project** comes in. The goal is to bring these legacy VM workloads into the modern Kubernetes ecosystem, creating a single, declarative platform for all your applications. The key technology to achieve this is **KubeVirt**. KubeVirt leverages the same **Kernel-based Virtual Machine (KVM)** technology that underpins the virtualized services of major public clouds like [GCP](https://cloud.google.com/compute/docs/instances/nested-virtualization/overview) and [AWS](https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/the-nitro-system-journey.html). It turns VMs into first-class citizens in a Kubernetes cluster, allowing them to be managed with the same **declarative**, **automated** principles as containers. This approach offers a path to: - **Cost Avoidance**: Break free from restrictive and expensive vendor licensing models by moving to a flexible, open-source solution. - **Unified Management**: Manage your entire workload—VMs and containers—from a single control plane. This reduces operational complexity and eliminates the need for siloed teams and disparate toolsets. - **Gradual Modernization**: Instead of a risky, all-at-once re-platforming, KubeVirt allows you to run existing VMs alongside new containerized applications. This enables a phased, low-risk approach to application modernization, where you can convert workloads to containers over time as needed. This strategy ensures that those untransformed VMs don't become a bottleneck for innovation or a drain on your budget. They can now benefit from Kubernetes' powerful orchestration capabilities, including automated scaling, consistent networking, and simplified security policies. **Further Resources for VM and Container Unification**: - [KubeV - Kubermatic's Virtualisation Solution](/products/kubermatic-virtualization/) - We've got a series on moving VMs into Kubernetes where we explore the topics, technologies, and adoption approaches in detail. We'd highly recommend a watch/listen (~30 min) or a read (4 min) on these links [Ep01](http://bit.ly/vm-kube-1rc), [Ep02](http://bit.ly/vm-kube-2rc). ## 2. The Portability Paradox: Replatforming for Cloud Independence ☁️ Moving applications from one cloud to another—whether for repatriation, multi-cloud, or sovereign reasons—is a significant undertaking. While **Infrastructure as Code (IaC)** promises easier portability, the reality is far more complex. The "Portability Paradox" is this: the deeper you integrate with a single cloud provider's high-order services, the more you risk vendor lock-in and the more difficult it becomes to move. It's has been common for organizations to lift and shift on-prem practices to the cloud, running VMs for databases and domain controllers instead of adopting managed services (DBaaS, SaaS). While this may feel familiar for operators, these untransformed workloads are now being scrutinized for their high cost and lack of flexibility. However, cost isn't the only driver. Legal and geopolitical pressures, such as the [U.S. CLOUD Act](https://www.congress.gov/bill/115th-congress/house-bill/4943), pose a direct conflict with European data protection laws like the GDPR. While the GDPR protects citizen data, the CLOUD Act can compel U.S.-based cloud providers—even those with data centers in Europe—to [hand over data to U.S. authorities](https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee/). This legal friction is leading governments, particularly in Europe, to seek genuine data sovereignty and re-evaluate their reliance on U.S. cloud services ([Denmark](https://www.euronews.com/next/2025/06/12/two-city-governments-in-denmark-are-moving-away-from-microsoft-amid-trump-and-us-big-tech-), [Netherlands](https://www.euronews.com/next/2025/03/20/a-threat-to-autonomy-dutch-parliament-urges-government-to-move-away-from-us-cloud-services)). For organizations in the UK, which has only one AWS region, relying on a single provider presents both a sovereignty and a resilience risk. **What are the Alternatives?** There are two primary architectural paths to address this paradox: **1. The Cloud Provider's On-Premise Solution**: Major cloud providers offer solutions to extend their public cloud into your data center, such as **AWS Outposts**, **Azure Stack**, and **Google Distributed Cloud**. While these products can address latency and data gravity concerns by placing compute closer to your data, they are essentially an 'extension' of public cloud, not a true escape from vendor lock-in. These solutions are tightly coupled to a single vendor's ecosystem, and their primary benefit is maintaining a consistent user experience, not reducing long-term costs or providing true portability. **2. The Cloud-Agnostic Kubernetes Platform**: A more strategic approach is to build with **cloud-native**, **open-source technology** that abstracts the underlying infrastructure. Kubernetes, with its common interfaces like CNI (networking) and CSI (storage), was designed for this purpose. It creates a portable execution environment for applications, freeing you from a single provider's proprietary services. The challenges to adopting Kubernetes when moving from public cloud does require thought about some foundational aspects of a cloud-comparative solution: - **Identity and Authentication**: Public clouds offer strong identity management like AWS IAM and Azure EntraID. When migrating from Public cloud, this can be replicated with a **service mesh** like Istio or Linkerd, which provides a consistent, platform-agnostic, zero-trust security model for all your applications, regardless of where they run. - **Stateful Workloads**: Moving stateful applications like databases is a common hurdle. The **Data on Kubernetes (DOK)** community, along with commercial solutions like Portworx, provides the tools to manage and protect stateful containers, making it possible to run critical databases anywhere (or VMs). - **Multi-Cluster Management**: As organizations grow, they adopt a **multi-cluster strategy** for isolation, security, and cost control—a pattern mirroring the use of separate accounts in public clouds. The challenge is managing this fleet without an increased operational overhead. Traditional Kubernetes distributions require cluster based management, This makes centralizing a large fleets of Kubernetes clusters laborious. This is where a purpose-built platform like **Kubermatic's Kubernetes Platform** comes in. It's designed to solve the part selection problem, and the multi-cluster issue. It enables the management of thousands of clusters from a single, centralized control plane that can be remote from the worker nodes. This architecture drastically reduces overhead and enables automated upgrades and centralized policy enforcement across hybrid and multi-cloud environments. By using a platform that can manage on prem and in public cloud, you can avoid the high control plane costs of managed Kubernetes services (AKS, EKS, GKE). Once your workloads are on this portable platform, you can easily move, adhere to changing sovereignty laws, and quickly adopt the latest tooling, including the AI capabilities. Particularly important in our age of AI; [Gartner predicts we will see 95% of new AI deployments on Kubernetes by 2028](/magic-quadrant-and-critical-capabilities-for-container-management/). This strategy provides a path to genuine cloud independence, not just a hardware-based extension of a single vendor's lock-in. **Further Resources for Portability Initiatives**: - [Kubermatic's smaller-scale Kuberentes offering KubeOne](/products/kubermatic-kubeone/), suited for multi-cluser administration across venues. - [Larger scale (over ~30 clusters) Kubermatic's Kubernetes Platform](/products/kubermatic-kubernetes-platform/), scales to 1000s of Clusters with a single control plane in a central location - [Stateful Kubernetes across any Storage using Portworx replacing Cloud's storage offerings](https://www.youtube.com/watch?v=74huOrHPnw4) - Opensource Object Storage to replace S3 or BLOB solutions [Min.io](https://www.min.io/) - [Distributed Global Load Balancing for remote clusters within Kubernetes using KubeLB over Layer 4 and Layer 7](/products/kubelb/) ## 3. Beyond the Datacenter: Architecting for Multi-Cluster and Edge Deployments 🌐 Containers have long been lauded for their portability and efficiency, packaging applications and their dependencies into small, fast, and self-contained units. This "build once, run anywhere" promise makes them ideal for environments with limited bandwidth and power. However, while a containerized workload is lightweight, the orchestration system required to manage it at scale, Kubernetes, traditionally is not. A single cluster needs significant compute and a reliable network, a challenge when you're no longer in a centralized data center. The future is about managing a **fleet of clusters** as **"cattle, not pets,"** which requires a fundamentally different architecture. Redundancy is key, but not all Kubernetes distributions are built for the harsh realities of the edge—like intermittent connectivity, resource constraints, and physical security risks. The UK government's **Software Defined Defence** pattern is a useful model for understanding the 'gradient' of edge environments. This model outlines a hierarchy of deployments, from the central, highly-connected data center to a "near edge" (e.g., a ship), and finally a "far edge" (e.g., a drone). Each layer has different requirements for connectivity, resilience, and local autonomy. <img src="/static/software-defined-defence.jpg" alt="UK Government's Advisory on Software Defined Defence" width="800" height="533" loading="lazy" style="display:block;height:auto;margin:20px auto;"> <small><em>image from UK Government's Advisory on Software Defined Defence bit.ly/sdd-25</em></small> We can apply this same multi-tiered pattern to civilian and commercial use cases. Consider the example of a **modern wind farm**. The central control center (operator's central DC) manages the entire fleet. A local edge (site control center) handles the local grid, while the IoT edge (the individual turbine) must operate autonomously to make real-time decisions, such as adjusting blades to prevent damage during a sudden change in wind. Today, these systems are managed with costly and inflexible bare-metal servers or VMs. The move to a containerized, Kubernetes-native approach at the edge allows for **fleet-wide automation**, drastically reducing the manual overhead of VM management. The challenge with traditional Kubernetes, however, is that its control plane (typically requiring 3 master nodes) must be located very close to its worker nodes. This architecture makes it impractical to centrally manage thousands of distributed edge sites. This is precisely the problem a new generation of Kubernetes platforms is designed to solve. A solution like **Kubermatic Kubernetes Platform** can run a fleet of 1,000+ clusters from a single, remote three node control plane. This architecture is built to handle intermittent connectivity and allows each edge cluster to operate autonomously, making local decisions based on pre-defined policies. This dramatically reduces the amount of infrastructure required at the edge, freeing up valuable compute power for high-impact work, like real-time analytics and AI inference, where it's most needed. **Further Resources for Edge Initiatives**: - [Kubermatic's Kubernetes Platform's (KKP) Edge capability explored](/products/kubermatic-kubernetes-platform/edge/) - [13 min webinar by CEO of Kubermatic on the application of Kubermatic at the Edge](/resources/born-in-the-cloud-growing-at-the-edge/) ## 4. The Golden Path: Improving Developer Experience with Kubernetes and Internal Developer Portals 🚀 Kubernetes was born from the learnings of Google's internal Borg system. Its design principles, much like the Site Reliability Engineering (SRE) discipline that also came from Google, these approaches are about managing systems at scale. This emphasis on **standardization**, **automation**, and **reliability** is the key to unlocking true developer velocity. A common misconception is that the "you build it, you run it" DevOps model scales indefinitely. While it works for small, often co-located teams, it quickly leads to **developer burnout** and inefficiency as teams are forced to solve the same infrastructure problems repeatedly. McKinsey discusses the idea of an [Inner Loop for app development and outer loops](https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity) for facilitating the running and enablement of that process including maintenance, debugging, and operational tasks, meetings etc. Building systems to reduce the amount of outer loop time enables velocity for organisations. Standardising sparingly, as the authors of Accelerate (Forsgren et al., 2018) A central finding was that high-performing organizations achieve both speed and stability by standardizing key areas like continuous integration and delivery (CI/CD). Using standards with extensibility allows developers to focus on what makes their application unique, while the underlying platform handles more outer-loop work. The solution to this challenge is to provide a ["Golden Path"](https://cloud.google.com/blog/products/application-development/golden-paths-for-engineering-execution-consistency) for developers, a concept of making the easiest route obvious and preferable . This is an opinionated, well-documented, and supported way to build and deploy software that bakes in an organization's best practices. The goal is to make the right way the easiest way. An **Internal Developer Portal (IDP)** serves as the hub for this Golden Path. It provides developers with self-service "primitives"—pre-configured, production-ready building blocks like database patterns, proxy configurations, and storage solutions. These are not just tools; they are the result of a dedicated platform team's work, honed for your specific environment. This **curated building-block** approach ensures that the platform aligns with the core principles of Kubernetes itself. This compliments popular offerings like Spotify's Backstage with its beautiful, presentation-rich front-end, A platform like **Kubermatic Developer Platform** is built to provide the underlying automation and orchestration, delivering a comprehensive solution that reduces toil for both developers and the platform team. Empowering developers to innovate with speed and confidence. **Further Resources for Edge Initiatives**: - [Kubermatic Developer Portal](/products/kubermatic-developer-platform/) - [Spotify Backstage, a front end focused Development Portal which compliments Kubermatic's Developer Portal](https://backstage.spotify.com/) - [Exploring APIs using Kubermatic towards Developer Portals](https://www.youtube.com/watch?v=IN2w4ekyL7Y) ## Where next? All of the approaches above build an understanding of modern technology supported by modern approaches. As the pace grows with AI, Machine Learning, and Agentic. Having a platform that's extensible and portable is going to be important. The importance of being better at implementing change is also key for Companies and Employees.Much of the Hype Cycle's other initiatives ([Cloud Sustainability](https://opencost.io/blog/carbon-costs/), [Serverless Infrastructure](https://serverlessworkflow.io/), [Intelligent](https://www.kubeflow.org/docs/components/spark-operator/overview/)[Platforms](https://docs.cloudera.com/csa-operator/1.1/overview/topics/csa-op-deployment-architecture.html), [BMaaS](https://docs.kubermatic.com/kubermatic/v2.28/architecture/supported-providers/baremetal/)) become more achievable faster with the platform and practices outlined above. So take a look at which are most urgent or have the biggest up-side to your organisation and step towards a more modern future. Thanks for reading [Anthony Hodson](https://linkedin.com/in/anthony-hodson) --- ## Cloud Native Live Webinar on kcp – Kubernetes-Like Control Planes for Declarative APIs - **URL:** https://www.kubermatic.com/resources/kcp-kubernetes-like-control-planes-declarative-apis/ - **Date:** 2025-10-24 - **Description:** This webinar explores the fundamental concepts of kcp, its usage of the Kubernetes Resource Model and how to publish and reconcile Kubernetes-like APIs to a multitude of users. # Cloud Native Live Webinar on kcp – Kubernetes-Like Control Planes for Declarative APIs ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Learn how you can use kcp to publish and reconcile Kubernetes-like APIs at scale. In the Cloud Native world declarative APIs are ubiquitous, enshrined in the Kubernetes Resource Model (KRM). Kubernetes Operators are built around this concept and Platform Engineering, an emerging discipline in the ecosystem, often centers around it as well. This continued success of the KRM raises a question: Why not use the Kubernetes API without the intention to orchestrate containers? [kcp](https://www.kubermatic.com/kcp/), a CNCF Sandbox project, adds stronger multi-tenancy and additional API management capabilities on top of the Kubernetes API server code. It supercharges the KRM to be used as a generic control plane for any kind of declarative APIs. Our webinar on kcp explores the fundamental concepts of kcp, its usage of the KRM and how to publish and reconcile Kubernetes-like APIs to a multitude of users. **Speakers:** - Marvin Beckers, *Team Lead at Kubermatic* - Simon Bein, *Senior Software Engineer at Kubermatic* ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Stop Playing Catch-Up: Secure Your Future Before the CRA Hits! - **URL:** https://www.kubermatic.com/resources/stop-playing-catch-up-secure-your-future-before-the-cra-hits-cds25/ - **Date:** 2025-10-10 - **Description:** Let's explore how Open Source already can help you to proactively assess and mitigate risks with tools for SBOM generation and threat detection. # Stop Playing Catch-Up: Secure Your Future Before the CRA Hits! ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Mario Fahlandt's talk at ContainerDays 2025 The clock is ticking. With the vulnerability reporting deadline in Q3 2026, and the full weight of the Cyber Resilience Act hitting in December 2027. That’s less time than you think to prepare for a seismic shift in digital product security. Are you ready for the CRA? Spoiler: Most aren’t. According to a Linux Foundation Survey, 62% of companies have low familiarity with the requirements. Don’t get caught flat-footed. “CYA before CRA” isn’t just a catchy phrase – it’s your survival strategy. Let’s explore how Open Source already can help you to proactively assess and mitigate risks with tools for SBOM generation and threat detection. How you can use the same tooling OSS is using to identify vulnerabilities before they become compliance nightmares. Learn to turn compliance into a competitive advantage by demonstrating your commitment to security and Open Source. This is an opportunity for companies and the OSS community to unite and address the CRA’s challenges collaboratively. **Speaker: Mario Fahlandt, Kubermatic Customer Delivery Architect** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Evaluating Global Load Balancing Options for Kubernetes in Practice - **URL:** https://www.kubermatic.com/resources/evaluating-global-load-balancing-options-for-kubernetes-in-practice-cds25/ - **Date:** 2025-10-10 - **Description:** Join us on our journey of evaluating the two CNCF projects Cilium and K8GB against real-world scenarios with complex multi-cloud deployments. # Evaluating Global Load Balancing Options for Kubernetes in Practice ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Tobias and Nicolai's talk at ContainerDays 2025 Load Balancing is a critical aspect of modern cloud deployments, and it’s especially tricky and misunderstood in hybrid environments that span across public clouds and private datacenters on premise. Designing a future-proof solution that is scalable, robust, fast and includes automatic failovers for different disaster cases, is a challenge we need to tackle. Therefore, our evaluation focused on two base technologies: Multi-Cluster Meshes and DNS based Global Load Balancing. Join us on our journey of evaluating the two CNCF projects Cilium and K8GB against real-world scenarios with complex multi-cloud deployments. Learn about the benefits, challenges and trade-offs you should expect when choosing a hybrid cloud strategy with Kubernetes! A practical live demo will share our hands-on experience, pros and cons, alongside use-case-specific solution recommendations for your hybrid-cloud journey. **Speakers: Nicolai Ort & Tobias Schneck** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## KubeVirt on the Loose: Kubernetes-Powered VM Migrations That Defy Gravity - **URL:** https://www.kubermatic.com/resources/kubevirt-on-the-loose-kubernetes-powered-vm-migrations-that-defy-gravity/ - **Date:** 2025-10-10 - **Description:** Learn best practices for migration timeouts, TLS toggling, and traffic isolation. # KubeVirt on the Loose: Kubernetes-Powered VM Migrations That Defy Gravity ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Ronny Issac's talk at ContainerDays 2025 This session is about freeing your workloads from the shackles of traditional maintenance windows. By dynamically relocating running Virtual Machines (VMs) between Kubernetes nodes, KubeVirt keeps apps online during upgrades, scaling, or node failures. Beneath the surface, KubeVirt orchestrates memory transfers and status checks, making VMs appear gravity-defying. “Pre-copy” sends most pages while VMs stay active, followed by a quick “stop-and-copy.” A “domain notify pipe” coordinates source and destination. For high dirty rates, “auto-converge” throttles CPU or “post-copy” starts the VM on the target, fetching pages on demand. Dedicated “migration0” and configurable parameters (e.g. completionTimeoutPerGiB) prevent stalls and manage bandwidth. Learn best practices for migration timeouts, TLS toggling, and traffic isolation. We’ll also explore real-world scenarios like draining nodes for maintenance or using auto-converge on heavy VMs. **Speaker: Ronny Issac, Engineering Team Lead at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Securing Kubernetes Clusters: From Access Control to System Hardening - **URL:** https://www.kubermatic.com/resources/securing-kubernetes-clusters-from-access-control-to-system-hardening/ - **Date:** 2025-10-10 - **Description:** Learn how to enforce least privilege with RBAC, block unauthorized traffic using Network Policies, and detect anomalies in real-time with tools like Falco. # Securing Kubernetes Clusters: From Access Control to System Hardening ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Rafraf & Rafik's talk at ContainerDays 2025 Kubernetes clusters are increasingly targeted by attackers due to misconfigurations and insufficient hardening. In this talk, we will address these challenges by diving into advanced security practices, including RBAC auditing, Network Policy testing, runtime security monitoring, and Linux-level hardening. You’ll learn how to enforce least privilege with RBAC, block unauthorized traffic using Network Policies, and detect anomalies in real-time with tools like Falco. Additionally, the session will cover how to reduce attack surfaces by implementing seccomp profiles, Linux Security Modules (AppArmor/SELinux), dropped capabilities, and sandboxing technologies (gVisor, Kata Containers). Attendees will leave with practical illustrations and actionable strategies to secure their Kubernetes environments effectively. **Speakers: Mohamed Rafraf & Rafik Harabi** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Building Europe's Cloud Future: NeoNephos and the Platform Mesh - **URL:** https://www.kubermatic.com/resources/building-europes-cloud-future-neonephos-and-the-platform-mesh/ - **Date:** 2025-10-10 - **Description:** Explore ApeiroRA (EU IPCEI-CIS), a reference architecture to unify the multi-provider cloud-edge continuum. # Building Europe’s Cloud Future: NeoNephos and the Platform Mesh ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Marvin & Mirza's talk at ContainerDays 2025 The open source ApeiroRA project, part of the EU initiative IPCEI-CIS, is a reference architecture for building a multi-provider cloud-edge continuum that should span the European continent. Some of the central questions the project wants to answer are: How can the different service offerings across a wide array of providers be unified? How can they communicate in a common language? We discuss how a combination of Cloud Native building blocks (kcp and kube-bind, among others) is used to create the foundation for the next generation of cloud platforms. We demonstrate a prototype which meshes together Kubernetes-like APIs that allows us to consume services across multiple control plane instances, instantiating what we call the “Platform Mesh”. This talk is for operators of cloud service providers and internal developer platforms (IDPs), giving them an outlook at a technology that unifies both worlds and creates a standard to consume services from (nearly) everywhere. **Speakers: Mirza Kopic & Marvin Beckers** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Dynamic Multi-Cluster Controllers with controller-runtime - **URL:** https://www.kubermatic.com/resources/dynamic-multi-cluster-controllers-with-controller-runtime-cds25/ - **Date:** 2025-10-10 - **Description:** Build dynamic multi-cluster controllers with controller-runtime! Learn to create a dynamic cluster provider for resources across a fleet of Kubernetes clusters. # Dynamic Multi-Cluster Controllers with controller-runtime ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Marvin & Stefan's talk at ContainerDays 2025 Controller-runtime is the most popular SDK to write controllers for individual Kubernetes clusters. But the Kubernetes landscape is changing quickly: multi-cluster is becoming ubiquitous (e.g. through Cluster API), with clusters joining and leaving dynamically. Controller-runtime has had no direct support, making writing uniform multi-cluster controllers hard and fracturing the emerging ecosystem. This talk explores how to build controllers that reconcile resources across a dynamic fleet of Kubernetes clusters. A key change is the ability to plug in a dynamic cluster provider that registers new Kubernetes clusters from a specific source. While implementation internals are briefly discussed, focus is on a hands-on walkthrough for writing your own cluster provider, event handlers and reconciler functions. We discuss a simplistic cluster provider implementation for “kind” clusters as an example and extrapolate from that how more complex providers could look like (e.g. for CAPI or kcp). **Speakers: Marvin Beckers & Stefan Schimanski** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Confidential Containers in action: decoding the peer pod approach - **URL:** https://www.kubermatic.com/resources/confidential-containers-in-action-decoding-the-peer-pod-approach/ - **Date:** 2025-10-10 - **Description:** CNCF Confidential Containers: Secure your cloud-native apps with confidential computing! Explore the vendor-agnostic stack, "peer pod" cloud approach, architecture, and a live demo. # Confidential Containers in action: decoding the peer pod approach ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Akash Gautam's talk at ContainerDays 2025 CNCF’s confidential containers project brings confidential computing to cloud-native workloads, it does so by providing a hardware vendor-agnostic software stack that builds a trusted execution environment (TEE) for cloud-native applications. One of the prerequisites for achieving confidential computing is having specialized hardware that supports confidential computing which might not be available at everyone’s disposal, to workaround this the confidential containers project provides a way to build TEE on major cloud providers with the help of cloud API adaptor utility, this approach is also known as the “peer pod” approach. In this session, I will explain the architecture of confidential containers on the bare-metal as well as cloud infrastructure, discuss the workflow and various operations like attestation, key management etc which are performed for deploying and running confidential applications & conclude with a demo of confidential containers using the peer pod approach. **Speaker: Akash Gautam, Consultant at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## From VMware to Kubernetes: Practical Demos & Strategic Roadmaps - **URL:** https://www.kubermatic.com/community/series-beyond-vmware/ - **Date:** 2026-05-14 - **Description:** Join experts online from Kubermatic, LiveWyer, and Portworx across three insightful sessions and lift your vision beyond simple migration, showing you how to truly transform your VM-centric applications. # Beyond VMware: Why Your Virtualization Migration is Just the Beginning ### Online Event on November 5, 2025 ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) - ![Kubermatic](/static/kubermatic-color.svg) - [![Livewyer](/static/livewyer.svg)](https://livewyer.io/) - [![Portworx by Everpure](/static/portworx-by-everpure.svg)](https://portworx.com/) ## From VMware to Kubernetes: Practical Demos & Strategic Roadmaps (Third Session) The tech industry is buzzing with discussions about escaping VMware costs, but what if we told you there's a much bigger opportunity? This series will lift your vision beyond simple migration, showing you how to truly transform your VM-centric applications. Join experts from Kubermatic, LiveWyer, and Portworx across three insightful sessions: The [first session](https://bit.ly/vm-kube-1) framed the challenge, introduced our strategic approach to transforming your VM-centric apps that enable a broader organizational shift. The [second session](https://bit.ly/vm-kube-2) looked into the tooling, technologies and benefits to team in moving VMs into Kubernetes. In this third online session, our experts will demonstrate practical migrations of workloads from VMware to Kubernetes Virtualisation considering their automation context and requirements. We will explore what a first project may be, options for a Proof of Value and investment needed to deliver the outcomes. We'll explore how the project's goals can be aligned with the strategy and constraints of your Organisation, including DORA or the CRA amongst others. Along the way, we'll share benefits from an Infrastructure, Engineering, and Security perspective. Then 'lift our vision' to understand what is possible for important workloads when Cloud Native is adopted effectively [Register Now](https://www.linkedin.com/events/7376989061716140032/) --- ## Introducing KubeLB 1.2: AI Gateway, Bare-Metal CLI, and Enterprise-Grade Reliability - **URL:** https://www.kubermatic.com/blog/introducing-kubelb-1-2-ai-gateway-bare-metal-cli-and-enterprise-grade-reliability/ - **Date:** 2026-04-30 - **Description:** KubeLB 1.2 is live. Explore all the new features including AI Gateway, Bare-Metal CLI, and more! - **Categories:** Company - **Tags:** KubeLB, Announcements - **Authors:** Csenger Szabo We are proud to announce **KubeLB 1.2**! This release marks a new era for KubeLB, expanding its reach beyond Kubernetes with a powerful new CLI, embracing the future of MLOps with AI Gateway integration, and fundamentally hardening the platform for the most demanding enterprise workloads. This release is a direct result of focused planning and feedback from our key customers and community. We set out with three primary goals: extend KubeLB's power to new environments, prepare for the next generation of intelligent applications, and deliver stability. ## Release Highlights of KubeLB 1.2 This release has several improvements, and three major features represent a leap forward for the project: 1. **The KubeLB CLI (Beta)**: For the first time, you can now manage high-performance L4 load balancing for applications running on **bare-metal and virtual machines**. **Tunneling** support has also been introduced to expose applications running on your local machine or inside a VM to the internet. The new CLI extends KubeLB's reach beyond the Kubernetes ecosystem, making it a truly universal load-balancing solution. 2. **AI Gateway Integration**: KubeLB is now AI-native. By integrating the open-source [Kgateway](https://kgateway.dev) and its powerful inference extension, we are providing intelligent, seamless traffic management for AI and machine learning workloads directly at the network edge. 3. **A New Foundation of Quality**: We have completely re-engineered our end-to-end testing framework with **Chainsaw**. This investment ensures KubeLB is more robust and reliable than ever before. ## KubeLB Community Edition (CE) Features The Community Edition is the heart of KubeLB, and version 1.2 brings plenty of new features focused on automation, flexibility, and an improved user experience. - **KubeLB CLI (Beta)**: The biggest new feature for CE is the KubeLB Command-Line Interface. Use a simple interactive CLI to manage load balancing configurations for your non-kubernetes applications, all managed and traffic served through KubeLB. - **Enhanced Security**: Every release of KubeLB CLI includes verified **Software Bill of Materials** (SBOMs) and **cryptographic signatures** to ensure the integrity and provenance of your downloads. - **KubeLB Addons**: KubeLB addons helm chart has been introduced to simplify installation and management of the addons that can be used with KubeLB such as Envoy Gateway, Ingress Nginx, etc. - **Load Balancer Hostname**: This allows users to specify a hostname for the load balancer. KubeLB then takes care of provisioning Ingress/Gateway API resources, DNS, and certificates etc. - **TenantState API**: To share current state of the tenant, including limits for load balancers, gateways, allowed domains, etc. with the tenants. Previously, this information was not accessible for the end-users or tenants of KubeLB and only available in the management cluster. - **Default Load Balancer Annotations**: You can now configure default annotations to be applied to all your LoadBalancer services, either globally or per-tenant. This is perfect for consistently applying required settings like cloud-specific location tags without manual intervention. - **Automated Gateway API Setup**: To streamline modern traffic management, the KubeLB CCM can now automatically install the necessary Gateway API CRDs directly into your tenant clusters. - **Simplified KKP Integration**: For users of the [Kubermatic Kubernetes Platform](/products/kubermatic-kubernetes-platform/), our Helm chart can now automatically manage the complex RBAC roles, service accounts, and tokens required for integration. - **Expanded E2E Testing**: Our new testing framework now includes comprehensive tests for **UDP services**, ensuring robust performance for DNS, VoIP, gaming, and other UDP-based applications. ## KubeLB Enterprise Edition (EE) Features KubeLB Enterprise Edition 1.2 is focused on providing cutting-edge capabilities and the integration required for large-scale, business-critical environments. - **AI Gateway Integration**: The headline feature for EE is the integration of the **Kgateway**, providing intelligent traffic routing for AI/ML inference workloads. This positions KubeLB as a critical component for any enterprise MLOps platform as running your AI, MCP, and Agent2Agent toolings alongside your data plane is a common use case. We are now leveraging **Kgateway** to solidify the integration with AI, MCP, and Agent2Agent toolings. - **Tunneling**: Support for tunneling has been introduced, allowing users to share applications running on their workstations or VMs either publicly over the internet or within their intranet network without worrying about firewalls, NAT, DNS, and certificate issues; it's all automated. - **Public APIs**: To empower our enterprise users and their automation workflows, the Enterprise Edition APIs are now public. This simplifies evaluation, integration with CI/CD systems, and allows for deeper programmatic control. ## Get Started with KubeLB 1.2 Today! KubeLB 1.2 is a statement about the future of networking. It's a platform that bridges the gap between traditional and cloud-native infrastructure, embraces the intelligence of AI, and is built on an enterprise-grade foundation of reliability. - **Check out the release on** [GitHub](https://github.com/kubermatic/kubelb) and give us a star! ;) - **Read our new [BGP Documentation](https://docs.kubermatic.com/kubelb/v1.2/)** We encourage all users to upgrade to v1.2 and explore the new capabilities that KubeLB has to offer. A huge thank you to our entire community, our customers, and the dedicated contributors who helped shape this incredible release. We can't wait to see what you build with KubeLB 1.2! --- ## The Great Migration: From VMware to Kubernetes, Tooling and Practices - **URL:** https://www.kubermatic.com/blog/the-great-migration-from-vmware-to-kubernetes-tooling-and-practices/ - **Date:** 2026-04-30 - **Description:** Discover the tools, practices, and strategies for migrating from VMware to Kubernetes. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Anthony Hodson This is the second installment in a three-part series on migrating from VMware to Kubernetes. We'll explore the tools and evolving practices that not only meet but exceed the needs of applications on their new platform. Even without modernizing the application runtime, moving to a cloud-native platform offers significant benefits. Part one covered the VMware and Broadcom backstory, "lift and shift" strategies, and the fundamental shift in operational models. We also discussed how to start, the concept of "anchored" workloads, and the benefits of a unified team context. You can catch up on [part one here](/blog/why-your-virtualization-migration-is-just-the-beginning/). ## Can We Trust an Open-Source Platform? For some, moving from a well-established virtualization platform like VMware to an open-source solution can be a concern. Let's clear this up: the underlying technology, **KVM (Kernel-based Virtual Machine)**, is a mature and proven technology that powers the virtualized services of all major cloud providers. **KubeVirt** then provides a user space layer that interacts with Kubernetes, bringing that proven virtualization capability into a cloud-native environment. For those accustomed to GUI environments, the transition doesn't mean giving up familiar interfaces. While an extensive and programmable **API** is available for building integrations and automation, you still have the option of using a **GUI** provided by solutions like Kubermatic's Virt. However, a significant trend in large enterprises is the move away from manual "click-ops" towards **automated**, **API-driven infrastructure**. The focus is shifting from an attractive GUI to programmability and integration with tools like Ansible, emphasizing that "the easier it is to automate, the better it is." Kubernetes, by design, supports this shift with its strong operational foundation, robust API, and abstract layers. ## Abstractions for Easier Management ### Storage Abstraction and Data Management Similar to VMware's VSAN, which provided a software-defined storage layer, **Portworx** fulfills this role in the Kubernetes ecosystem, providing enterprise data management features. These capabilities include crucial functions like cross-site replication, point-in-time snapshots, and on-disk encryption, all essential for VM environments. Portworx addresses the need for data to travel with the workload beyond a single data center. For compliance, particularly with regulations like DORA, Portworx allows you to define different **storage classes** with varying data protection rules and SLAs, simplifying management at scale. The API-driven nature of both Kubernetes and Portworx enables developers to self-serve, including backup and restore operations, with safeguards baked in to meet internal user expectations. For example, GitOps can trigger a backup on a production environment before rolling out a change. ## Disaster Recovery and Operational Resilience Once a VM is moved into Kubernetes, it becomes a first-class citizen, treated like any other containerized deployment. This means VMs benefit from Kubernetes' flexible **dynamic scheduler**, which can operate across multiple data centers. This declarative approach, where you define what you want the system to do, is a significant shift from the manual, imperative placement of workloads in traditional VMware models. Kubernetes was designed to be highly resilient, using **quorum** with an odd number of servers. This offers a major advantage over VMware's active-passive setup and can lead to hardware savings. The operational maturity of Kubernetes ensures that disaster recovery and operational resilience are **baked in**, which is vital for meeting stringent recovery time objectives (RTOs), such as the two-hour window mandated by regulations like DORA. ## Modern Networking and Security Kubermatic Virt offers a **"virtual private cloud" paradigm** for networking. The **Container Network Interface (CNI)** allows services within your cloud-native namespace to interact directly with virtual machines. This enables you to define and deploy applications as a single manifest, making them highly portable and enabling **ephemeral environments**. Imagine being able to safely test on digital clones of production, tucked away in a separate cluster with the same controls as production itself. Kubernetes also opens the door to using mature **service meshes** like Linkerd or Istio. These provide an overlay of logic for networking, extending capabilities such as pod-to-pod or pod-to-VM encryption. They also offer centralized tracing, metrics, and logging, consolidating operational insights into a single source. ## Migration Strategies The best approach for migrating VMs depends on their current maturity. For older VMs with minimal configuration management, a **"lift and shift" of the base VM image** is an option, using tools like Forklift and Packer. However, a key **anti-pattern** to avoid is failing to assess whether the processes within the VM could be more efficiently containerized. For organizations using configuration management (Ansible, Salt, Chef, Puppet), migration is straightforward: you create the new host and apply your existing scripts. Once a system is running in a Kubernetes VPC that supports both containers and VMs, breaking out components of a workload becomes much easier. ## Benefits for Workloads and Operators Alike Moving VMs into Kubernetes is a safe landing zone for engineers familiar with VMware, allowing them to leverage their existing knowledge of VMs, KVM, and Linux while acquiring new Kubernetes skills. This transition is a great opportunity to address technical debt by thinking about things like failover and scaling upfront. For storage administrators, this is a chance to integrate their expertise with containerized workloads and bring their knowledge of data protection and high availability to a modernized environment. The move from a "garden-walled" platform to an open-source one is a significant draw, especially when guided by a known good combination of tools, which is what companies like Kubermatic offer. This is just a glimpse of the topics covered in the session. You'll be all set for our final session, **"From VMware to Kubernetes: Practical Demos & Strategic Roadmaps"**, in person and recorded live on September 23, 2025 @3pm Location: The CitizenM Towerbridge, London. [Register here](https://bit.ly/vm-kube-live) --- ## What KKP Users Need to Know about the Bitnami Registry Changes - **URL:** https://www.kubermatic.com/blog/what-kkp-users-need-to-know-about-the-bitnami-registry-changes/ - **Date:** 2026-04-30 - **Description:** Bitnami will significantly change its container image registry on August 28, 2025. Learn what this means for KKP users and how to avoid service disruptions. - **Categories:** Products - **Tags:** KKP - **Authors:** Csenger Szabo On August 28, 2025, the container image registry at `docker.io/bitnami` will be permanently decommissioned. This change impacts any software relying on images hosted under `docker.io/bitnami/*`. If you do not take action before the deadline the **User Cluster MLA feature in your KKP clusters may stop working**. ## Why Is Bitnami Shutting Down the Registry? Bitnami is drastically reducing its free image offering. After **August 28th, 2025**, the `docker.io/bitnami` registry will only host a small set of images intended for development and not production-ready, and only under the `latest` tag. Everything else is moving to a **Bitnami Legacy** repository, which won’t get updates or security patches, and should only be used briefly during migration. The official announcement can be found on [GitHub](https://github.com/bitnami/charts/issues/35256). ## Why This Matters for KKP Users Kubermatic Kubernetes Platform (**KKP**) uses Bitnami images for Cortex. Cortex is the component behind the User Cluster MLA feature. When the Bitnami registry goes offline, these components will no longer be able to pull the required images. This means that **backup and MLA features could fail** in environments that still depend on `docker.io/bitnami`. ## What We’re Doing To mitigate this, we have updated KKP to remove dependencies on the Bitnami registry. Our latest **patch release** includes alternative image sources to ensure these features continue to work. ## What You Need to Do **Before August 28, 2025**, make sure you: 1. **Upgrade your KKP installation to the latest patch release** ([v2.28.2](https://github.com/kubermatic/kubermatic/releases/tag/v2.28.2), [v2.27.7](https://github.com/kubermatic/kubermatic/releases/tag/v2.27.7), [v2.26.12](https://github.com/kubermatic/kubermatic/releases/tag/v2.26.12)). 2. Validate that your clusters are pulling images from the new image sources. If you do not upgrade by the deadline, your **MLA features will stop functioning properly**. **TBD before going public**: Customers who are completely unable to upgrade to a newer KKP version may use a workaround. This should be treated as a last resort method and comes with downsides on future upgrades. Specifically, with the patch releases, we are also moving to mirrored helm-charts to ensure stability and independence going forward. This workaround will not migrate to the mirrored charts, it will only switch images. Workaround in detail: 1. Add the following to your mla values.yaml ```yaml # add at the top level cortex: memcached-blocks-index: image: registry: quay.io repository: kubermatic-mirror/images/memcached metrics: image: registry: quay.io repository: kubermatic-mirror/images/memcached-exporter memcached-blocks: image: registry: quay.io repository: kubermatic-mirror/images/memcached metrics: image: registry: quay.io repository: kubermatic-mirror/images/memcached-exporter memcached-blocks-metadata: image: registry: quay.io repository: kubermatic-mirror/images/memcached metrics: image: registry: quay.io repository: kubermatic-mirror/images/memcached-exporter ``` 2. Re-run the mla installation process in accordance with the official documentation with a kubermatic installer matching your current KKP version https://docs.kubermatic.com/kubermatic/v2.28/tutorials-howtos/monitoring-logging-alerting/user-cluster/admin-guide/#installing-mla-stack-in-a-seed-cluster ## ​​Need help? Thank you for being a part of the Kubermatic community. If you find our contributions valuable, we kindly encourage you to leave a star on our [GitHub repository](https://github.com/kubermatic/kubermatic). As always, please don’t hesitate to reach out with any questions or suggestions via [Contact Us](/contact-us/) form. --- ## Scaling Kubernetes the Right Way: Platform Engineering Lessons from Kubermatic - **URL:** https://www.kubermatic.com/resources/scaling-kubernetes-the-right-way-platform-engineering-lessons-from-kubermatic/ - **Date:** 2025-08-14 - **Description:** Scaling Kubernetes the Right Way: Platform Engineering Lessons from Kubermatic # Scaling Kubernetes the Right Way: Platform Engineering Lessons from Kubermatic ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Sebastian Scheele's interview for SoftwarePlaza podcast Sebastian Scheele, CEO of Kubermatic, shares insights on running Kubernetes at scale, the evolution of platform engineering, and the power of using the Kubernetes API to build developer self-service platforms. He discusses managing thousands of clusters, simplifying infrastructure for developers, and integrating AI workloads. Plus, get a live demo of how Kubermatic enables seamless multi-cloud Kubernetes management, all while staying true to open-source principles. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Kubermatic Named in Gartner® Magic Quadrant™ for Container Management - **URL:** https://www.kubermatic.com/blog/kubermatic-named-in-gartner-magic-quadrant-for-container-management/ - **Date:** 2026-04-30 - **Description:** Get your complimentary copy of the 2025 Gartner® Magic Quadrant™ for Container Management. - **Categories:** Company - **Tags:** Announcements We're proud to share that **Kubermatic has been named in the 2025 Gartner® Magic Quadrant™** for Container Management. Kubermatic is the only company currently headquartered in Germany recognized in this Magic Quadrant™. We believe this recognition reinforces our commitment to helping enterprises simplify and scale their Kubernetes operations across hybrid, multicloud, and edge environments. _"We believe our position highlights our specialized focus on solving the toughest challenges in complex, distributed Kubernetes environments across multi-cloud, hybrid, and edge. We are proud to be recognized by Gartner® and for us, this acknowledgment validates our commitment to providing powerful, open-source solutions for enterprises and service providers tackling the most demanding infrastructure challenges."_ Sebastian Scheele, CEO <div style="float:right;clear:both;margin:0 0 15px 10px;"> <img src="/static/magic-quadrant-and-critical-capabilities-for-container-management-img.png" alt="Gartner® Magic Quadrant and Critical Capabilities for Container Management" width="366" height="405" loading="lazy" style="display: block;height: auto;"> </div> ## Why this matters now This recognition comes as the importance of container management continues to grow. According to Gartner, "by 2028, 95% of new AI deployments will use Kubernetes, up from less than 30% today". As organizations accelerate their digital transformation, Kubernetes is becoming the foundation for modern applications and AI-driven workloads. And Kubermatic is at the forefront of this movement, allowing enterprises to unlock the full potential of Kubernetes. Big trends shaping this space: ### Cloud sovereignty is becoming critical In a changing geopolitical landscape, the need for data control and regulatory compliance has become a strategic imperative. Adopting a sovereign-capable infrastructure strategy is key. Kubermatic stands out with [KubeV](/products/kubermatic-virtualization/), which allows companies to build their own private cloud, ensuring they have full control over their IT deployments. ### Open source matters more than ever The Importance of Open-Source Strategies is huge, and enterprises need to prioritize open-core platforms to avoid vendor lock-in. Kubermatic's open-core approach with [KKP](/products/kubermatic-kubernetes-platform/) and [active contributions](/company/community/#ossprojects) to CNCF make this possible. ## Looking Ahead Being recognized in the Gartner® Magic Quadrant™ for Container Management is a significant moment for us. Thank you to our customers and community for trusting us to help you build and scale your platforms. If you'd like to dive deeper into how vendors were evaluated, you can access the full report below. [Download your complimentary copy of the 2025 Gartner® Magic Quadrant™ for Container Management](/magic-quadrant-and-critical-capabilities-for-container-management/) <br/> --- <small> <em> <strong>Disclaimer:</strong> Gartner, Magic Quadrant for Container Management, Dennis Smith, Wataru Katsurashima, Tony Iams, Lucas Albuquerque, Michael Warrilow, Stephanie Bauman, 6 August 2025 <br><br>GARTNER is a registered trademark and service mark of Gartner and Magic Quadrant is a registered trademark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and are used herein with permission. All rights reserved. <br>Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose. </em> </small> <br><br> --- ## Gartner® Magic Quadrant and Critical Capabilities for Container Management - **URL:** https://www.kubermatic.com/magic-quadrant-and-critical-capabilities-for-container-management/ - **Date:** 2026-07-07 - **Description:** Discover Gartner® Magic Quadrant and Critical Capabilities for Container Management where Kubermatic got named as a Niche Player # “By 2028, 95% of new AI deployments will use Kubernetes, up from less than 30% today.” Gartner® Magic Quadrant for Container Management ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Complimentary Gartner® ## Magic Quadrant for Container Management Published 06 August 2025 [Download the Report](/magic-quadrant-and-critical-capabilities-for-container-management/#report) ![Gartner® Magic Quadrant and Critical Capabilities for Container Management](/static/magic-quadrant-and-critical-capabilities-for-container-management-img.png) A recent report published by Gartner® has named Kubermatic in its Magic Quadrant and recognized in the Critical Capabilities for Container Management analysis. We're proud to be the **only company currently headquartered in Germany** and the **sole vendor recognized as a Niche Player** in this Magic Quadrant. We see this as an endorsement of our strategic direction. Our expertise is concentrated on the most demanding areas of the modern IT landscape, including the intricate management of multicluster Kubernetes, a commitment to open-source-first strategies, and pioneering edge computing solutions. **Discover why Kubermatic was recognized and get the full landscape of the container management market, getting the insights you need to build your future-proof infrastructure strategy. Access your complimentary copy of the 2025 Gartner® Magic Quadrant™ for Container Management report today.** If our form couldn't load correctly – This can have multiple reasons like ad blocker, not accepted cookies, JavaScript deactivated. However, you can still get in touch with us! Simply click on the button below, and you'll be able to submit the form and reach out to us for any inquiries or assistance you need. [Open form](https://share.hsforms.com/1pGMGAe47SfaPDdI9GzXqcA2piu8) * * * ***Gartner, Magic Quadrant for Container Management, Dennis Smith, Wataru Katsurashima, Tony Iams, Lucas Albuquerque, Michael Warrilow, Stephanie Bauman, 6 August 2025***
 ***Gartner, Critical Capabilities for Container Management, 6 August 2025, Tony Iams, Michael Warrilow, Lucas Albuquerque, Wataru Katsurashima, Dennis Smith. Gartner is a registered trademark and service mark and Magic Quadrant is a registered trademark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and are used herein with permission. All rights reserved.*** ***This graphic was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. Gartner does not endorse any vendor, product or service depicted in its research publications and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.*** ## Our Upcoming Events [![Proud partner of WeAreDevelopers World Congress Europe, 8-10 July, Berlin](/static/event-wearedevelopers26_hu_1cbbc2a6515d782.jpg)](https://www.wearedevelopers.com/) Onsite Conference ## [Join us in Berlin at WeAreDevelopers](https://www.wearedevelopers.com/) [Join Here](https://www.wearedevelopers.com/) [![](/static/containerdays-hamburg-2026_hu_d4a7201e201462bf.jpg)](https://www.containerdays.io/containerdays-hamburg-2026/) Onsite Conference ## [ContainerDays Hamburg is Back in the Harbor of Hamburg for 2026!](https://www.containerdays.io/containerdays-hamburg-2026/) [Join Here](https://www.containerdays.io/containerdays-hamburg-2026/) ## Ready to try Kubermatic Kubernetes Platform? [Get Your Free Demo](/demo/) --- ## Gartner® Magic Quadrant and Critical Capabilities for Container Management - **URL:** https://www.kubermatic.com/topics/gartner-magic-quadrant/ - **Date:** 2025-08-11 - **Description:** Everything you need to know about Gartner® Magic Quadrant and Critical Capabilities for Container Management # Gartner® Magic Quadrant and Critical Capabilities for Container Management ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Jump To Section [What is Gartner?](#what-is-gartner) [What is Gartner Magic Quadrant™?](#what-is-gartner-magic-quadrant) [How does a Gartner Magic Quadrant™ work?](#how-does-a-gartner-magic-quadrant-work) [What does the Gartner® Magic Quadrant and Critical Capabilities for Container Management cover?](#what-does-the-gartner-magic-quadrant-and-critical-capabilities-for-container-management-cover) [How many vendors are included in the Gartner® Magic Quadrant™?](#how-many-vendors-are-included-in-the-gartner-magic-quadrant) [Why was Kubermatic included?](#why-was-kubermatic-included) [How can I get a copy?](#how-can-i-get-a-copy) ## What is Gartner? Gartner®, Inc. is a leading global technology research and advisory firm. It provides senior leaders across various industries with objective, expert-led insights, research, and tools to help them make critical decisions and achieve their mission-critical priorities. Gartner® analysis is widely respected and frequently used by businesses to evaluate technology trends and vendors. ## What is Gartner Magic Quadrant™? The Gartner® Magic Quadrant™ is a series of market research reports that provide a graphical positioning of technology vendors within a specific market. Vendors are evaluated on two key criteria: their “Ability to Execute” (how well they deliver and support their product today) and their “Completeness of Vision” (their strategy and innovation for the future). This analysis places them into one of four quadrants: Leaders, Challengers, Visionaries, or Niche Players, giving you a high-level view of the market’s participants and their relative positions. ## How does a Gartner Magic Quadrant™ work? A Magic Quadrant™ provides a graphical competitive positioning of four types of technology providers, in markets where growth is high and provider differentiation is distinct: - Leaders execute well against their current vision and are well positioned for tomorrow. - Visionaries understand where the market is going or have a vision for changing market rules, but do not yet execute well. - Niche Players focus successfully on a small segment. Deliver deep expertise and tailored solutions for particular use cases or customer types. Niche Players are recognized for doing one thing exceptionally well. - Challengers execute well today or may dominate a large segment, but do not demonstrate an understanding of market direction. ## What does the Gartner® Magic Quadrant and Critical Capabilities for Container Management cover? ### What the Gartner® Critical Capabilities for Container Management Covers: The Critical Capabilities report is a companion document that provides a deep-dive technical evaluation of the vendors’ products. It is designed to help you choose the best solution for your specific needs. **Specifically, it covers**: **Product & Service Scoring**: It scores each vendor’s product against a set of essential features that Gartner has identified as “critical.” For Gartner® Critical Capabilities for Container Management 2025 report, these capabilities include: - Cloud Deployment - On Premises Deployment - AI / Machine Learning - IT Operations - Security and Governance - Container Platform Functions **Use Case Analysis**: It often weighs these scores against common real-world use cases (e.g., “Enterprise Platform Teams,” “Edge Computing,” “Application Modernization”) to show which products are best suited for different scenarios. In short, the Critical Capabilities report answers the question: *“Which vendor’s product is the best technical fit for my specific use cases and requirements?”* ## How many vendors are included in the Gartner® Magic Quadrant™? The Gartner® Magic Quadrant 2025 report includes a selection of the 15 vendors. Each vendor is evaluated on two key criteria: their “Ability to Execute” (how well they deliver and support their product today) and their “Completeness of Vision” (their strategy and innovation for the future). ### What does it mean to be a Niche Player? Niche Players focus successfully on a small segment. Deliver deep expertise and tailored solutions for particular use cases or customer types. Niche Players are recognized for doing one thing exceptionally well. ## Why was Kubermatic included? Kubermatic was included because Gartner® named Kubermatic as a Niche Player in Gartner® Magic Quadrant™ and Recognized in the Critical Capabilities for Container Management. Niche Players are often masters of a particular area. In this context, we believe it reflects a deep focus on solving the most complex challenges in Kubernetes, such as multi-cluster management, hybrid/edge deployments, and cloud sovereignty, rather than being a one-size-fits-all solution. - Excelling in multicluster Kubernetes management - Leading in open-source-first strategies or edge computing - Serving specific industries or geographies better than generalist vendors. ## How can I get a copy? You can access a complimentary copy of *Gartner® Magic Quadrant and Critical Capabilities for Container Management* directly from [this page](/magic-quadrant-and-critical-capabilities-for-container-management/). --- ## Stop Playing Catch-Up: A Deep Dive into the Cyber Resilience Act and Your Ticking Clock - **URL:** https://www.kubermatic.com/blog/stop-playing-catch-up-a-deep-dive-into-the-cyber-resilience-act-and-your-ticking-clock/ - **Date:** 2026-04-30 - **Description:** Find out how the Cyber Resilience Act (CRA) is pushing companies to contribute to open source. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Joana Figueiredo You might think your smart coffee machine is just a simple appliance. But in the eyes of European law, it's a digital product with a whole new set of rules to follow. A recent talk by Mario Fahlandt, our Customer Delivery Architect and active open-source contributor, broke down the seismic shift that is the Cyber Resilience Act (CRA), and the message was clear: the clock is ticking, and most companies aren't even aware they're in a race. The CRA is not just another piece of regulation; it's a first-of-its-kind, mandatory cybersecurity law that impacts virtually every product with a digital element sold in the European Union. This isn't just about toys and smartwatches; it covers everything from industrial control systems to any piece of hardware or software that can connect to a network. {{< youtube "https://www.youtube.com/embed/KkjQI20IFtE" >}} ## The Clock is Ticking: Key Deadlines You Can't Ignore The Cyber Resilience Act officially entered into force in December of last year, meaning, as Mario bluntly put it, "you're already too late." However, there is a transition period with critical deadlines to mark on your calendar. - **September 11, 2026**: This is a crucial date. By this time, you must be able to report exploited vulnerabilities to the authorities within 24 hours. - **End of 2027**: The CRA goes into full effect. From this point forward, you will not be able to sell any product in the EU without the CE marking signifying cyber resilience compliance. As of the talk, Mario did the math for us: "You have one year, one month, and 20 days to be CRA compliant." ## Why Now? The Driving Forces Behind the CRA The European Union didn't enact this sweeping legislation on a whim. It's a direct response to several alarming trends: 1. **A Flood of Insecure Products**: The EU market was being flooded with products, with glaring security holes and no one responsible for patching them. 2. **Devastating Vulnerabilities**: Incidents like Log4Shell demonstrated how a single flaw in one open-source project could wreak havoc across thousands of companies. 3. **Skyrocketing Cybercrime**: The cost of cybercrime is projected to dwarf the entire estimated $8.8 trillion value of the open-source ecosystem already this year by $2 trillion according to statista. ## A Fundamental Shift: Security by Design, Default, and Responsibility The CRA is built on two foundational principles that change how products are developed and maintained. - **Security by Design**: Security can no longer be an afterthought. It must be a core consideration from the very first moment a product is conceived. - **Security by Default**: The days of default passwords for printers or other devices are over. Products must be shipped in a secure state out of the box. This legislation also fundamentally shifts liability. The responsibility for cybersecurity now rests squarely on the shoulders of the **manufacturer**. This includes performing due diligence on all components, including the open-source software they use. ### The New Open Source Dynamic: From Consumer to Contributor This shift in liability radically alters the relationship between companies and the open-source community. For years, the dynamic has been companies consuming open-source software and pressuring maintainers to fix bugs. The old adage, "Open source maintainers owe you nothing," has been the unofficial rule. Under the CRA, that changes. If you use an open-source component in your commercial product, you are responsible for its security. This means manufacturers are now compelled to fix vulnerabilities in the open-source code they use and contribute those fixes back upstream. As Mario puts it, "You are now more or less forced to contribute to open source." ## The Cost of Non-Compliance: More Than Just a Fine If you think you can ignore the CRA, think again. The penalties are severe and designed to be a powerful deterrent. - **Massive Fines**: Violators face fines of up to €15 million or 2.5% of their total worldwide annual turnover—whichever is higher. - **Market Ban**: Perhaps even more devastating, non-compliant companies can be banned from selling their products in the entire European Union. ## Your Toolkit for Compliance: From SBOMs to DevSecOps The challenge of compliance may seem daunting, but the open-source community has already built the tools you need. Mario emphasizes that the solution is to integrate security into every step of the development lifecycle. In other words, "DevSecOps is now law." Here's a practical toolkit to get you started: 1. **Software Bill of Materials (SBOM)**: You can't secure what you don't know you have. An SBOM is a detailed inventory of every software component in your product. Tools like **[Syft](https://github.com/anchore/syft)** can automatically generate these for you. 2. **Vulnerability Scanning**: Once you have your inventory, you need to scan it for known vulnerabilities. This is essential, as the CRA requires you to ship products with no known exploitable vulnerabilities. Open-source tools like **[Grype](https://github.com/anchore/grype)** are perfect for this. 3. **Understand Your Supply Chain**: Having machine-readable SBOMs is great, but you need to understand the relationships and dependencies within your software. This is where **[GUAC](https://github.com/guacsec/guac)** comes in. This open-source project creates a graph of all your software dependencies, allowing you to quickly identify which products are affected by a new vulnerability or even check the licenses of all the packages you use. 4. **Automate Everything**: Manually performing these checks is impossible at scale. These tools must be integrated into your automated CI/CD pipelines to ensure continuous compliance. ## Your Action Plan: An Executive-Level TLDR Feeling overwhelmed? Mario provided a clear, step-by-step action plan for every company leader. 1. **Assess Your Portfolio**: Immediately identify which of your products are affected by the CRA and assess your risk and scope. 2. **Form a Task Force**: This is not just an IT problem. Your task force must include people from product management, procurement, legal, and engineering to tackle this challenge holistically. 3. **Identify Gaps**: Analyze your current systems and processes to find where you fall short of the CRA's requirements. 4. **Develop a Roadmap**: Create a clear, time-bound plan to achieve compliance. Remember, the final deadline is fixed. 5. **Create an Open Source Strategy**: Get involved with the community. Contributing to open source is no longer just good corporate citizenship; it's a business necessity that gives you insight and influence over the components critical to your products. ## The CRA Is an Opportunity, Not a Threat The Cyber Resilience Act is undoubtedly a monumental challenge. It demands a new way of thinking about software development and responsibility. But as Mario concluded, it's actually a good thing. The CRA establishes a high, global cybersecurity standard that originates from Europe. It pushes the entire industry to create safer, more secure products. For companies willing to take the lead, this is a golden opportunity. No customer will ever refuse to buy your product because it's too secure. Being able to market your products as fully CRA-compliant before the 2027 deadline is not a burden; it's a significant competitive advantage. The time to start is now. Mario will further explore the Cyber Resilience Act in his talk at [ContainerDays](https://www.containerdays.io/containerdays-conference-2025/), in September. Don't miss him in Hamburg! --- ## Stop Playing Catch-Up: Secure Your Future Before the CRA Hits! - **URL:** https://www.kubermatic.com/resources/stop-playing-catch-up-secure-your-future-before-the-cra-hits/ - **Date:** 2025-07-31 - **Description:** Let's explore how Open Source already can help you to proactively assess and mitigate risks with tools for SBOM generation and threat detection. # Stop Playing Catch-Up: Secure Your Future Before the CRA Hits! ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Mario Fahlandt's talk at Cloud Native Summit Munich 2025 The clock is ticking. With the vulnerability reporting deadline in Q3 2026, and the full weight of the Cyber Resilience Act hitting in December 2027. That’s less time than you think to prepare for a seismic shift in digital product security. Are you ready for the CRA? Spoiler: Most aren’t. According to a Linux Foundation Survey, 62% of companies have low familiarity with the requirements. Don’t get caught flat-footed. “CYA before CRA” isn’t just a catchy phrase – it’s your survival strategy. Let’s explore how Open Source already can help you to proactively assess and mitigate risks with tools for SBOM generation and threat detection. How you can use the same tooling OSS is using to identify vulnerabilities before they become compliance nightmares. Learn to turn compliance into a competitive advantage by demonstrating your commitment to security and Open Source. This is an opportunity for companies and the OSS community to unite and address the CRA’s challenges collaboratively. **Speaker: Mario Fahlandt, Customer Delivery Architect at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Building a Platform Engineering API Layer with KCP - **URL:** https://www.kubermatic.com/resources/building-a-platform-engineering-api-layer-with-kcp-cloud-native-summit-2025/ - **Date:** 2025-07-31 - **Description:** kcp expands the scope of platform engineering beyond the boundaries of individual Kubernetes clusters, transforming the scale at which platform teams and internal service providers can operate. This talk will cover patterns for both service providers and developers, highlighting how kcp simplifies their workflows. # Building a Platform Engineering API Layer with KCP ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Simon Bein's talk at Cloud Native Summit Munich 2025 Self-service is a central aspect of platform engineering, and platform engineering teams frequently build on top of Kubernetes to utilize its powerful API design. The kcp project was accepted into the CNCF Sandbox in 2023 and extends Kubernetes API concepts beyond container orchestration. This talk will explore how kcp enhances platform engineering with a global control plane for all internal services. As a central API layer, kcp facilitates a SaaS-like interaction between internal service providers and developers, turning internal developer platforms into a service-oriented marketplace—all using familiar concepts and tools that Kubernetes developers already know and love. kcp expands the scope of platform engineering beyond the boundaries of individual Kubernetes clusters, transforming the scale at which platform teams and internal service providers can operate. This talk will cover patterns for both service providers and developers, highlighting how kcp simplifies their workflows. **Speaker: Simon Bein, Senior Software Engineer at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## The Forrester Wave™: Multicloud Container Platforms, Q3 2025 - **URL:** https://www.kubermatic.com/topics/forrester-wave-multicloud-container-platforms/ - **Date:** 2025-10-29 - **Description:** Everything you need to know about Forrester Wave™: Multicloud Container Platforms # The Forrester Wave™: Multicloud Container Platforms, Q3 2025 ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Jump To Section [What is Forrester?](#what-is-forrester) [What is The Forrester Wave™?](#what-is-the-forrester-wave) [What does the Multicloud Container Platforms Wave cover?](#what-does-the-multicloud-container-platforms-wave-cover) [How many vendors are included?](#how-many-vendors-are-included) [Why was Kubermatic included?](#why-was-kubermatic-included) ## What is Forrester? Forrester is a global research and advisory firm. It helps business and technology leaders make informed decisions using independent research, data, and analysis. Forrester is widely respected for its expertise in digital, cloud, and technology strategy. ## What is The Forrester Wave™? The Forrester Wave™ is a report that evaluates vendors in a specific market. For each report, Forrester analysts research the space, define evaluation criteria, and compare the strengths and weaknesses of each vendor. Companies are scored objectively and grouped into categories such as Leaders, Strong Performers, Contenders, and Challengers. ## What does the Multicloud Container Platforms Wave cover? This report evaluates container platforms that help enterprises manage Kubernetes clusters across multiple environments, including public cloud, private infrastructure, and edge locations. It focuses on how platforms handle automation, scaling, lifecycle management, AI support, and edge use cases. ## How many vendors are included? The Q3 2025 report includes a selection of the 9 top multicloud container platform providers. Each vendor is evaluated against 31 specific criteria that assess current offering, strategy, and market presence. ## Why was Kubermatic included? Kubermatic was included because Forrester recognizes it as one of the 9 top multicloud container platform providers. In the report, Forrester states: - *“Kubermatic is a good fit for companies seeking a highly automated and scalable infrastructure on which to base a bigger platform.”* - *[KKP](/products/kubermatic-kubernetes-platform/) is also described as appealing to “cost-conscious IT leaders who value simplicity over platform bloat, especially advanced Kubernetes users.”* - *Additionally, Forrester noted KKP’s K8sGPT AI operator, which was “launched ahead of much larger players”.* --- ## Kubermatic Recognized in The Forrester Wave™: Multicloud Container Platforms, Q3 2025 - **URL:** https://www.kubermatic.com/blog/kubermatic-recognized-in-the-forrester-wave-multicloud-container-platforms-q3-2025/ - **Date:** 2026-04-30 - **Description:** Get your complimentary copy of The Forrester Wave™: Multicloud Container Platforms, Q3 2025 - **Categories:** Company - **Tags:** Announcements We're proud to share that **Kubermatic has been named one of the 9 top vendors** in The Forrester Wave™: Multicloud Container Platforms, Q3 2025 report. The Forrester Wave™ is one of the industry's most trusted guides for enterprises choosing multicloud container platforms. This report evaluates vendors against 31 criteria, covering their current offering, strategy, and customer feedback. With this recognition, we believe Kubermatic joins a select group of providers shaping the future of multicloud container solutions. > _"We believe that Kubermatic's recognition in the Forrester Wave™ reflects our commitment to automation, scalability, and open source," said Sebastian Scheele, CEO and Co-Founder of Kubermatic. "Our goal has always been to deliver a lean, efficient platform that makes running Kubernetes at scale simple. To us, this acknowledgment confirms that open, focused platforms are key to the future of the Kubernetes ecosystem."_ <div style="float:right;clear:both;margin:0 0 15px 10px;"> <img src="/static/forrester-wave-multicloud-container-platforms-q3-2025-img.png" alt="The Forrester Wave™: Multicloud Container Platforms, Q3 2025" width="366" height="474" loading="lazy" style="display: block;height: auto;"> </div> Julian Hansert, Kubermatic COO and Co-Founder, added that _"Multicloud, edge, and AI are reshaping IT, and our focus is to help enterprises thrive in that shift. We see this recognition as proof that our vision resonates with what the industry truly needs."_ We believe Kubermatic was recognized as a **Contender** because we are gaining strong traction and driving innovation in the multicloud container space. According to Forrester, _"Kubermatic earns respect from Kubernetes-savvy users for its focus on core operations, open-source contributions, and automation."_ The report also states that _"Kubermatic appeals to cost-conscious IT leaders who value simplicity over platform bloat, especially advanced Kubernetes users"_, and that _"Kubermatic is a good fit for companies seeking a highly automated and scalable infrastructure on which to base a bigger platform"_. Forrester further notes Kubermatic's open-source contributions, above-par control plane configuration, and automation across major U.S. cloud providers, on-premises environments, and disconnected edge deployments. Additionally, the report noted Kubermatic's early launch of **K8sGPT**, our AI-powered Kubernetes operator, which came "ahead of much larger players." The Kubermatic Kubernetes Platform (KKP) is designed for teams who already know Kubernetes, and want to run it their way. Kubermatic focuses on **automation, scalability, and simplicity** without adding unnecessary overhead. Renowned enterprises such as Lufthansa, Bosch, Siemens, Cube Bikes, Allianz, and T-Systems rely on Kubermatic to lead their cloud-native journey. ## Looking Ahead Being recognized in the Forrester Wave™ is a significant milestone, and one we're proud of. It reinforces our belief that lean, open, and focused platforms have a vital role to play in the evolving Kubernetes ecosystem. We're grateful to our customers and community who trust us to help them build and scale their platforms, and to Forrester for highlighting our progress. <br/> --- <small> <em> <strong>Disclaimer:</strong> Forrester does not endorse any company, product, brand, or service included in its research publications and does not advise any person to select the products or services of any company or brand based on the ratings included in such publications. Information is based on the best available resources. Opinions reflect judgment at the time and are subject to change. For more information, read about Forrester's objectivity <a href="https://www.forrester.com/about-us/objectivity/" target="_blank">here</a></strong>. </em> </small> <br><br> --- ## Why Your Virtualization Migration is Just the Beginning - Part 2 - **URL:** https://www.kubermatic.com/resources/why-your-virtualization-migration-is-just-the-beginning-part-2/ - **Date:** 2025-07-28 - **Description:** This series will lift your vision beyond simple migration, showing you how to truly transform your VM-centric applications. Check out the second session. # Why Your Virtualization Migration is Just the Beginning - Part 2 ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## VMWare to Kubernetes, unpacking the technologies… The tech industry is buzzing with discussions about escaping VMware costs, but what if we told you there’s a much bigger opportunity? This series will lift your vision beyond simple migration, showing you how to truly transform your VM-centric applications. Join experts from Kubermatic, LiveWyer, and Portworx across insightful sessions. We’ll share our experience, data, and understanding to guide you on how to move, modernize, and maintain your VM-based applications. **Second Online Session**: In this second session we build on the information shared in Session 1 (Selecting, Planning, People, and Possibilities) and we explore the tooling more specifically, including the diligence we develop in workloads allowing them to thrive in Kubernetes. We’ll cover the way teams will interact differently with the tooling and why that’s helpful. And the benefits of the thriving and open ecosystem these workloads are joining. **Speakers:** **Anthony Hodson, UK Technical Sales, Kubermatic** **Daniel Banche, Senior Systems Engineer, Portworx by Pure Storage** **David O’Dwyer, Director, Livewyer** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Why Your Virtualization Migration is Just the Beginning - Part 1 - **URL:** https://www.kubermatic.com/resources/why-your-virtualization-migration-is-just-the-beginning-part-1/ - **Date:** 2025-07-28 - **Description:** This series will lift your vision beyond simple migration, showing you how to truly transform your VM-centric applications. Check out the first session. # Why Your Virtualization Migration is Just the Beginning - Part 1 ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Slash VMware Costs, Unleash Cloud-Native Agility: Your Path to a Future-Proof Enterprise The tech industry is buzzing with discussions about escaping VMware costs, but what if we told you there’s a much bigger opportunity? This series will lift your vision beyond simple migration, showing you how to truly transform your VM-centric applications. Join experts from Kubermatic, LiveWyer, and Portworx across insightful sessions. We’ll share our experience, data, and understanding to guide you on how to move, modernize, and maintain your VM-based applications. **First Online Session**: We frame the challenge, introduce our strategic approach to transforming your VM-centric apps, and highlight the tools that enable a broader organizational shift. **Speakers:** **Anthony Hodson, UK Technical Sales, Kubermatic** **Daniel Banche, Senior Systems Engineer, Portworx by Pure Storage** **David O’Dwyer, Director, Livewyer** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Why your Virtualization Migration is just the beginning - **URL:** https://www.kubermatic.com/blog/why-your-virtualization-migration-is-just-the-beginning/ - **Date:** 2026-04-30 - **Description:** Let's cut through the noise and provide a clear roadmap for this essential digital transformation journey. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Anthony Hodson The Shifting Sands: Why Move from VMs? The recent acquisition of VMware by Broadcom and the subsequent increase in costs have left many in the industry feeling alienated and concerned. However, as discussed in our session, moving away from a VM-centric world isn't just about cost savings. It's about achieving greater agility, fostering a happier and more autonomous staff, and embarking on a broader digital transformation journey. Think of it like moving house: it's an opportunity to shed what you don't need, understand your current estate, and align with a future vision, rather than just a "lift and shift". ## Moving from Vmware? A Hybrid World It's important to understand that the transition isn't an "all or nothing" approach. Many organizations will operate in a hybrid environment, balancing traditional VM-based workloads with new containerized services. In fact, it's increasingly possible to run virtual machines inside Kubernetes, allowing for consistent management through a single specification or "manifest". This consistency is crucial for agility, enabling easy creation of copies, parallel testing, and spinning up ephemeral environments. ## Where to Start Your Modernization Journey? Consider the data – its value, criticality, and access patterns. Whether data is read-only or involves destructive interactions (writes) significantly influences whether it stays with VMs or moves to a containerized context or can be removed all together! Begin with workloads that are as well-known as possible to understand the "unknown unknowns" and the boundaries of your current estate, especially for legacy VMs that may have been running for 20 years. This is a chance for thorough housekeeping and discovery. **Prioritize Productivity Gains**: Focus on services where modernization can deliver the most significant productivity gains for developers. Services with long feedback loops (e.g., a week-long deployment pipeline) are ideal candidates, as containerization can drastically reduce this to minutes, providing immense value and getting teams on board. ## Pitfalls and Anti-patterns **Unrealistic Timelines**: Don't expect to move hundreds of VMs in a single year. This is a gradual process that requires safety and careful execution, not just speed. **Lack of Due Diligence**: Avoid simply treating every VM the same. It's critical to interrogate the workload running within each VM. Don't skip the review by assuming it's easier to keep a VM as is; often, parts can be containerized with additional effort. **Oversized VMs**: Don't move a VM that consumes an entire underlying hardware instance directly into Kubernetes without re-evaluating its purpose. **Ignoring Dependencies**: Failing to understand your application's dependencies is a major challenge. Tools can help, but ultimately, you'll need a better grasp of how your applications work. **Hasty Decisions**: Rushing the discovery process or being "lazy" in due diligence can lead to significant unexpected costs. ## Benefits **The Power of Unification and Kubernetes**: Moving to a containerized or Kubernetes space forces you to think differently about your workloads, defining liveness, health, and what "working" truly means. **This shift can lead to profound benefits**: **Improved Recovery and Efficiency**: Kubernetes can reschedule a downed service in seconds, dramatically reducing recovery times compared to traditional VM failovers (which might take 5-10 seconds). This can even lead to hardware savings as you might need fewer instances for high availability. **Standardization and Consistency**: You achieve a unified and standardized approach to managing all your workloads, whether VM-based or containerized. **Team Alignment**: When teams operate within a similar context and speak the same language, collaboration improves, and they can rely on platforms to provide consistent capabilities. **Portability and Strength**: Embracing open-source and open-core solutions provides greater portability and puts you in a position of strength in discussions with providers. This transformation is about systematically making gains and validating your understanding of each service as it transitions. It's a continuous journey of trust and proof. {{< youtube "https://www.youtube.com/embed/14FbniYzW9s" >}} --- ## Tackling the Titans: A Preview of Kubermatic's Sessions on Multi-Cluster, Security & the CRA at ContainerDays Conference 2025 - **URL:** https://www.kubermatic.com/blog/tackling-the-titans-a-preview-of-kubermatics-sessions-on-multi-cluster-security-and-the-cra-at-containerdays-conference-2025/ - **Date:** 2026-04-30 - **Description:** Join Kubermatic at ContainerDays 2025 as we tackle the titans of cloud-native challenges. - **Categories:** Community - **Tags:** Open Source Projects - **Authors:** Sebastian Scheele The best part of any conference is the people you meet and the ideas you share. The cloud-native community is gearing up for one of Europe's premier events, [ContainerDays Conference 2025](https://www.containerdays.io/containerdays-conference-2025/) in Hamburg (September 9-11), and we couldn't be more excited to connect with you all. Last year, many of you joined our CEO, Sebastian Scheele, for an incredible fireside chat with the one and only Kelsey Hightower. The conversation was a major highlight, and this year, the story continues! We're thrilled to see **Kelsey Hightower featured on the main stage again**, asking a characteristically provocative question: _"Why are we still talking about containers?"_ when OS-level virtualization is now 25 years old. <img src="/static/kelsey-hightower-and-sebastian-scheele-kubermatic.jpg" alt="Kelsey Hightower and Sebastian Scheele Kubermatic" width="800" height="534" loading="lazy"> It's exactly this kind of forward-thinking, challenging conversation that drives our community forward. In that same spirit, the Kubermatic team is excited to take the stage with a whole new set of sessions designed to tackle cloud-native's biggest questions. We've put together this guide to our talks to help you join us on a journey of discovery. Whether you're curious about the future of platforms or looking for practical solutions to today's problems, there's a conversation waiting for you. [Here's a look at the key themes we're bringing to Hamburg.](/containerdays-conference-2025/) ## Discovering the Future of Platforms at Scale If you're curious about how we'll manage the ever-growing complexity of multi-cloud and multi-cluster environments, we have several sessions that look over the horizon. Join **Marvin and Stefan Schimanski to get a hands-on guide for** ["Dynamic Multi-Cluster Controllers with controller-runtime" (🔹9 September, 11:10 - Stage K1)](https://www.containerdays.io/containerdays-conference-2025/agenda/#sz-session-885504). Then, come discover the ambitious "Platform Mesh" concept for Europe with **Mirza Kopic (SAP) and Marvin Beckers in their talk**, ["Building Europe's Cloud Future: ApeiroRA and the Platform Mesh" (🔹10 September, 10:10 - Stage K1)](https://www.containerdays.io/containerdays-conference-2025/agenda/#sz-session-884878). To complete the picture of what's next, **Lovro Sviben and Simon Bein** will show you how to use kcp and Crossplane to build the [Next Generation of Platform Engineering Using kcp and Crossplane (🔹9 September, 14:25 - Stage P1)](https://www.containerdays.io/containerdays-conference-2025/agenda/#sz-session-898397). ## Exploring Practical Solutions for Today's Infrastructure A vision for the future also requires solving the challenges right in front of us. For those focused on modernizing real-world workloads, we have several deep dives. Discover how to free your applications from maintenance windows with **Ronny Paul Issac** in ["KubeVirt on the Loose: Kubernetes-Powered VM Migrations That Defy Gravity" (🔹11 September, 09:00 - Stage K4)](https://www.containerdays.io/containerdays-conference-2025/agenda/#sz-session-898438). If you're navigating the complexities of hybrid networking, join **Tobias Schneck** and **Nicolai Ort** for their practical session, ["Evaluating Global Load Balancing Options for Kubernetes in Practice," (🔹10 September, 12:30 - Stage K6)](https://www.containerdays.io/containerdays-conference-2025/agenda/#sz-session-885557) complete with a live demo. And because security is foundational, don't miss **Mohamed Rafraf** and **Rafik Harabi** talk on ["Securing Kubernetes Clusters: From Access Control to System Hardening"(🔹9 September, 16:45 - Stage P1)](https://www.containerdays.io/containerdays-conference-2025/agenda/#sz-session-898610) where he'll share actionable strategies for hardening your environments. ## Preparing for the Next Wave of Change What new regulations and technologies are on the horizon? We invite you to explore the answers with us. **Mario Fahlandt** will deliver an essential and timely session, ["Stop Playing Catch-Up: Secure Your Future Before the CRA Hits!," (🔹11 September, 13:00 - Stage K6)](https://www.containerdays.io/containerdays-conference-2025/agenda/#sz-session-902354) offering a proactive strategy for the upcoming Cyber Resilience Act. And for a look at the cutting edge of data protection, join **Akash Gautam** as he decodes the "peer pod approach" in his talk on ["Confidential Containers in action: decoding the peer pod approach" (🔹11 September, 09:45 - Stage P1)](https://www.containerdays.io/containerdays-conference-2025/agenda/#sz-session-898178). <img src="/static/iphone-picture.jpg" alt="iphone picture" width="800" height="534" loading="lazy"> We can't wait to share these ideas, learn from your experiences, and connect with the community in Hamburg. Mark your calendars, be sure to say hello to our speakers after their talks, grab the cool swag, and have fun at the **Kubermatic booth C5**. See you at [ContainerDays Conference 2025](https://www.containerdays.io/containerdays-conference-2025/agenda/)! --- ## Meet KubeOne 1.11 - Supporting Kubernetes 1.33 - **URL:** https://www.kubermatic.com/blog/meet-kubeone-1-11-supporting-kubernetes-1-33/ - **Date:** 2026-04-30 - **Description:** The KubeOne 1.11 release introduces support for Kubernetes 1.33, image mirroring for air-gapped environments, advanced configuration APIs, and improved CA bundle management. - **Categories:** Products - **Tags:** KubeOne - **Authors:** Artiom Diomin We're excited to announce that KubeOne 1.11 is now available! KubeOne is our open-source cluster lifecycle management tool, which automates cluster deployment and management in your preferred on-prem, edge, or cloud environment. This release focuses on improving KubeOne's flexibility and includes new features aimed at advanced configuration, image management, and Kubernetes 1.33 support. Here's what's new in KubeOne 1.11: **Support for Kubernetes 1.33**: As always, we're committed to supporting the latest Kubernetes versions. KubeOne 1.11 introduces support for [Kubernetes 1.33](https://kubernetes.io/blog/2025/04/23/kubernetes-v1-33-release/), ensuring you can leverage the latest upstream features and improvements. All managed components are updated for full compatibility and performance. **New `mirror-images` Command**: We're introducing a new `mirror-images` helper command, allowing you to create a mirror of all images used by KubeOne. This is especially useful for air-gapped environments or organizations with strict registry policies. **Control Plane and Static Workers Annotations API**: With 1.11, we've added support for annotating control plane nodes and static workers via the KubeOne API. This makes it easier to attach metadata and custom logic to specific node roles, and enables you to support more advanced automation workflows. **Override Containerd Sandbox Image**: KubeOne 1.11 allows you to override the default containerd sandbox image. This feature helps align your environment with internal image policies or use region-specific mirrors to speed up provisioning. **Improved `caBundle` API**: We've made it easier to manage custom Certificate Authorities. You can now provide a CA bundle from a file, simplifying integration with custom PKI setups. **Automatic CA Injection for Add-ons**: Add-ons now automatically receive `caBundle` volumes, volume mounts, and environment variables. This reduces the need for manual configuration and ensures that add-ons have access to your cluster's trusted certificate authorities by default. We hope [KubeOne 1.11](https://github.com/kubermatic/kubeone) helps you manage your Kubernetes clusters with greater ease! For more details, check out the [changelog](https://github.com/kubermatic/kubeone/tree/main/CHANGELOG) and upgrade instructions. As always, we'd love to hear your feedback. Reach out to us on our {{< slackjoinlink "Community Slack" >}} or on [GitHub](https://github.com/kubermatic/kubeone)! --- ## The New Era of Resilience in the Cloud - **URL:** https://www.kubermatic.com/blog/the-new-era-of-resilience-in-the-cloud/ - **Date:** 2026-04-30 - **Description:** Discover why resilience is the pragmatic next step for Europe's cloud infrastructure. - **Categories:** Community, Best Practices - **Tags:** Kubernetes, Open Source Projects - **Authors:** Julian Hansert _Digital sovereignty might be a political dream. But resilience is not._ According to [Statista (2025)](https://www.statista.com/chart/18819/worldwide-market-share-of-leading-cloud-infrastructure-service-providers/), the Big Three American cloud providers - AWS, Microsoft and Google - currently hold 62% of the global market share. But with growing geopolitical instability and rising protectionism, companies across Europe are starting to question [their dependence on US cloud giants](/blog/is-europe-breaking-up-with-us-cloud-giants/). One of the major causes for concern is the [CLOUD Act](https://www.cov.com/en/news-and-insights/insights/2018/03/cloud-act-creates-new-framework-for-cross-border-data-access), which allows US authorities to access data stored by American tech firms, even if it is physically stored outside the US. That means European company data hosted on US-owned platforms isn't entirely out of reach for US law enforcement. Understandably, EU businesses are growing wary. There's concern about potential misuse of the CLOUD Act, or worse, a complete shutdown from the American side. In response, over 100 organizations have signed an [open letter](https://www.the-guild.eu/news-and-blog/news/2025/open-letter-in-support-of-fp10.html) urging European officials to push for greater technological independence. ## Security wake-up call To address growing risks, the EU has passed the [Cyber Resilience Act (CRA)](https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act). This regulation requires companies to fulfill mandatory cybersecurity requirements throughout the entire lifecycle of their products. The goal is to hold vendors accountable and to give buyers confidence that [CE-marked](https://single-market-economy.ec.europa.eu/single-market/goods/ce-marking_en) products meet a trustworthy cybersecurity standard. At [KubeCon + CloudNativeCon Europe 2025](https://www.forrester.com/blogs/kubecon-2025-technology-resilience-sovereignty-and-security-in-an-era-of-political-change/), security and resilience were among the most pressing topics. Speakers warned that there’s currently "too little choice in the market, and too much power concentrated in too few hands". ## Digital sovereignty: Ambition or Illusion? [Digital sovereignty](https://www.weforum.org/stories/2025/01/europe-digital-sovereignty/) is a powerful idea: the ability to have control over your data, hardware, and software. As for Cloud sovereignty, it's about having control, ownership, and jurisdiction over your data and infrastructure. No external dependencies. No foreign jurisdiction. Total autonomy. At KubeCon, data sovereignty also took the main stage. Speakers and analysts warned about the dangers of single-provider dependency and advised a strong push toward open-source technologies to avoid vendor lock-in and retain control. New European projects are starting to emerge in an effort to build sovereignty, such as [NeoNephos](https://neonephos.org/). This project brings together cloud-native experts, developers, and providers to build a sovereign cloud infrastructure in Europe. But full digital sovereignty is extremely difficult to achieve in practice. As noble as it sounds, full digital sovereignty is still a political dream. We're part of a global supply chain, most foundational software libraries are maintained in the US or China, and for now, Europe's cloud ecosystem is still working to match some capabilities of the US hyperscalers. So yes, sovereignty is a goal worth working towards. But for most companies, it's not achievable in the short term. It's a political vision, but not a practical blueprint (yet). The pragmatic solution now is resilience. ## Resilience - the pragmatic next step While full digital sovereignty might remain an ambition, resilience is something we can actually build today. Resilience means having options. It means designing cloud architectures that include US hyperscalers, European cloud providers, and private cloud environments. Instead of relying on a single provider, companies should think in terms of redundancy, portability, and failover. We can think of US clouds like electricity: we still use them, but we shouldn't rely on just one grid. We need backups in place so we're not left in the dark when something breaks. In cloud terms, that means running critical workloads across private environments, sovereign platforms, and multi-cloud setups that let you "hot-swap" between providers when needed. This is the core of a **Second Platform Strategy**: not cutting ties with US providers, but reducing risk through diversity, flexibility, and control. By building resilience into the architecture itself, companies can stay operational, no matter what the political or regulatory climate throws at them. ## Looking ahead As the cloud-native ecosystem matures, resilience will become the new default. That means: - Prioritizing **Zero Trust** architecture. - Diversifying supply chains and infrastructure locations. - Using open-source. The road to digital sovereignty is long. But resilience is something we can build now. For companies looking to take back control of their cloud environments, solutions like [Kubermatic Virtualization](/products/kubermatic-virtualization/) (KubeV) and [Kubermatic Developer Platform](/products/kubermatic-developer-platform/) (KDP) offer a powerful alternative. With KubeV, organizations can build and manage their own private cloud infrastructure entirely with Kubernetes. It's a strong fit for companies handling sensitive data, offering greater flexibility and helping ease privacy concerns. --- ## Meet Kubermatic @ ContainerDays Conference 2025 in Hamburg - **URL:** https://www.kubermatic.com/containerdays-conference-2025/ - **Date:** 2026-03-30 - **Description:** Visit our booth at ContainerDays Conference 2025 in Hamburg and check out what cool stuff we've planned for you. ![Kubermatic branding element](/static/containerdays-conference-2025-header-bg.jpg) # Meet us at ContainerDays Conference 2025! Everything is set for ContainerDays in Hamburg on September 9-11, 2025 and we are looking forward to seeing you there! ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Visit the Kubermatic Booth for the Best Experience! - #1 ### SWAG & Popcorn Engage not only in insightful conversations with our experts but also enjoy various fun-filled activities, grab our sweet plush toys & have some popcorn with us! - ![Announce icon](/static/announce-icon-grad.svg) ### Live Demos: Platform Engineering at Kubermatic Learn everything about the Kubermatic products at the booth together with our experts. It's time to accelerate your cloud native transformation! ![Conversation between Sebastian and Julian](/static/picture-of-founders-630x464.jpg) ## Meet our Experts Running Kubernetes at scale, meeting security and compliance requirements, and deploying Kubernetes clusters spanning on-premise or multiple public clouds can introduce an increasing amount of complexity. **Request a meeting with our Founders or experts onsite to discover how to easily master all these challenges and drive your business forward!** [Request a Meeting](mailto:marketing@kubermatic.com) ## Check out the Kubermatic talks! - ### Dynamic Multi-Cluster Controllers with controller-runtime September 9. 11:10 AM CEST Stage K1 - ![Marvin Beckers, Team Lead at Kubermatic](https://sessionize.com/image/6827-200o200o2-DmXTJFU727V3rYtEa1kgkJ.jpg)Marvin Beckers, Team Lead at Kubermatic - ![Stefan Schimanski, Principal Engineer at Nvidia](https://sessionize.com/image/0dc2-200o200o2-hL4v8Vfh5HXAGRRyCSEjrs.jpg)Stefan Schimanski, Principal Engineer at Nvidia [Check it out](https://www.containerdays.io/containerdays-conference-2025/agenda/#sz-session-885504) - ### Next Generation of Platform Engineering Using kcp and Crossplane September 9. 02:25 PM CEST at Stage P1 - ![Simon Bein, Software Engineer at Kubermatic](https://sessionize.com/image/0802-200o200o2-7TD2qxtKeFzcTBGrbtS8tR.jpg)Simon Bein, Software Engineer at Kubermatic - ![Lovro Sviben, Senior Distributed Systems Engineer at Upbound](https://sessionize.com/image/862c-200o200o2-KjPPLtSLP4SdvgrGCSDKZD.jpeg)Lovro Sviben, Senior Distributed Systems Engineer at Upbound [Check it out](https://www.containerdays.io/containerdays-conference-2025/agenda/#sz-session-898397) - ### Securing Kubernetes Clusters: From Access Control to System Hardening September 9. 04:45 PM CEST at Stage P1 - ![Mohamed Rafraf, Platform Engineer at Kubermatic](https://sessionize.com/image/3581-200o200o2-XJMntP9WxJQBYb1jL6Bsp5.png)Mohamed Rafraf, Platform Engineer at Kubermatic - ![Rafik Harabi, Senior Solutions Architect at Sysdig](https://sessionize.com/image/d6e1-200o200o2-EsKH2kQRjod3C9eXUrRDEb.png)Rafik Harabi, Senior Solutions Architect at Sysdig [Check it out](https://www.containerdays.io/containerdays-conference-2025/agenda/#sz-session-898610) - ### Building Europe's Cloud Future: NeoNephos and the Platform Mesh September 10. 10:10 AM CEST at Stage K1 - ![Marvin Beckers, Team Lead at Kubermatic](https://sessionize.com/image/6827-200o200o2-DmXTJFU727V3rYtEa1kgkJ.jpg)Marvin Beckers, Team Lead at Kubermatic - ![Mirza Kopic, Principal Engineer and Lead Architect at SAP](https://sessionize.com/image/c4c9-200o200o2-EDgfNjEHn6JCL81k9eyLLo.jpg)Mirza Kopic, Principal Engineer and Lead Architect at SAP [Check it out](https://www.containerdays.io/containerdays-conference-2025/agenda/#sz-session-884878) - ### Evaluating Global Load Balancing Options for Kubernetes in Practice September 10. 12:30 PM CEST at Stage K6 - ![Tobias Schneck, Principal Architect at Kubermatic](https://sessionize.com/image/d06b-200o200o2-c2-370f-4095-948d-094246854aca.c33b576a-d509-4cc9-8fd1-ee16ae83fde1.png)Tobias Schneck, Principal Architect at Kubermatic - ![Nicolai Ort, Cloud Platform Engineer at Datev](https://sessionize.com/image/971f-200o200o2-sY7wdaUevh2axnV5ZeNSqG.jpg)Nicolai Ort, Cloud Platform Engineer at Datev [Check it out](https://www.containerdays.io/containerdays-conference-2025/agenda/#sz-session-885557) - ### KubeVirt on the Loose: Kubernetes-Powered VM Migrations That Defy Gravity September 11. 9:00 AM CEST at Stage K4 - ![Ronny Isaac, Engineering Team Lead at Kubermatic](https://sessionize.com/image/4e3a-200o200o2-BM9oQTygrktUqDhVrYY8nJ.jpg)Ronny Isaac, Engineering Team Lead at Kubermatic [Check it out](https://www.containerdays.io/containerdays-conference-2025/agenda/#sz-session-898438) - ### Confidential Containers in action: decoding the peer pod approach September 11. 09:45 AM CEST at Stage P1 - ![Akash Gautam, Consultant at Kubermatic](https://sessionize.com/image/5a79-200o200o2-wachDbeFTw7yyw1tuSu7cU.jpg)Akash Gautam, Consultant at Kubermatic [Check it out](https://www.containerdays.io/containerdays-conference-2025/agenda/#sz-session-898178) - ### Stop Playing Catch-Up: Secure Your Future Before the CRA Hits! September 11. 01:00 PM CEST at Stage K6 - ![Mario Fahlandt, Service Delivery Architect at Kubermatic](https://sessionize.com/image/1ce0-200o200o2-nApmz7com2FCQSzRfgpm8D.png)Mario Fahlandt, Service Delivery Architect at Kubermatic [Check it out](https://www.containerdays.io/containerdays-conference-2025/agenda/#sz-session-902354) --- ## Meet KKP 2.28: More Security and Control with Kyverno Integration - **URL:** https://www.kubermatic.com/blog/kkp-2-28-more-security-and-control-with-kyverno-integration/ - **Date:** 2026-04-30 - **Description:** Discover what's new in KKP 2.28: Kyverno integration, global viewer role, Kubernetes 1.33 support, improved backups with Velero, and more. - **Categories:** Products - **Tags:** KKP - **Authors:** Csenger Szabo We're excited to announce the release of [Kubermatic Kubernetes Platform (KKP)](/products/kubermatic-kubernetes-platform/) 2.28! This version introduces new features to enhance security, simplify cluster operations, and give teams more control (without added complexity). Let's explore the highlights of KKP 2.28! ## Kyverno Integration: Policy Enforcement Reimagined One of the most anticipated integrations is now available. KKP 2.28 introduces a monumental improvement in security and compliance, with deep Kyverno integration. Kyverno, a powerful Kubernetes-native policy engine, allows you to manage admission control policies directly as Kubernetes resources. With this powerful integration, you can now: - **Enforce Policies Directly in User Clusters**: Deploy and utilize Kyverno controllers within your user clusters, enabling precise policy enforcement at the workload level. - **Consistent Policy Deployment Across KKP**: As a Platform Admin, you can now establish organization-wide policies, or Project owners can define policies tailored to their specific needs, ensuring consistent governance across your entire KKP setup. - **Robust Policy Enforcement and Defaulting**: Leverage Kyverno to enforce and default policies across all your Kubernetes clusters managed by KKP, ensuring compliance and adherence to best practices. - **Comprehensive Policy Management within the Dashboard**: Gain immediate access to a curated default policy catalog to jumpstart your policy definitions. Additionally, KKP's intuitive UI allows you to craft custom policies to meet your specific security and compliance requirements. ## Disaster Recovery and Cluster Migration with Velero-Powered Backup & Restore KKP 2.28 introduces a major upgrade in disaster recovery and cluster migration, with enhanced Velero-based backup and restore features, including: - **Backup uploads directly from the dashboard**: You can now upload your backup files directly to your configured S3 bucket via the KKP dashboard. This process allows you to quickly restore those backup files to a new Kubernetes User Cluster within KKP. - **Source labels for backup objects**: We've introduced the ability to label backup objects with their source. This intelligent tagging makes it easier to organize, identify, and retrieve specific backups. ## Introducing the Global Viewer Role in KKP 2.28 KKP 2.28 introduces another long-awaited feature: the Global Viewer role. In this role, users can monitor all resources and configurations in a read-only format, without the ability to make any modifications. This global viewer role enhances transparency across the platform, allowing team members and auditors to monitor infrastructure without impacting it or requiring administrative privileges. ## Embracing the Future: Kubernetes 1.33 Support KKP 2.28 brings full support for Kubernetes 1.33, allowing teams to benefit from the latest upstream improvements and features. ## Robust KubeVirt Enhancements For users leveraging **KubeVirt**, this release delivers multiple upgrades: - Improved provisioning of KubeVirt VMs with `MatchSubnetAndStorageLocation`, ensuring better network and storage compatibility. - Our network policy controller now supports an explicit policy mode (allow or deny), giving you more control over network traffic. - You can now define vCPU values for KubeVirt VMs and set a CPU allocation ratio to optimize resource utilization. - The filtration of storage classes has been improved, so only compatible storage classes are shown during provisioning, with KubeVirt Storage Class Infra Cluster Filtration. - Enhanced compatibility checks for KubeVirt deployments with KubeVirt Subnet and StorageClasses Location Compatibility. ## Upstream Chart Adoption for MLA Stack Our MLA (Monitoring, Logging, Alerting) stack has been updated to leverage upstream charts. This includes upstream Helm charts, such as Alertmanager, kube-state-metrics, and blackbox-exporter for improved maintainability and quicker access to the latest community updates. ## Streamlined Image Management Working with mirrored images is now more user-friendly and efficient than ever. We've delivered an improved `mirror-images` experience and introduced a new `mirror-binaries` subcommand, simplifying offline deployments. You can also ensure all necessary images are mirrored for your Cilium deployments with mirroring for the Cilium-Envoy image. ## Greater Control and Customization We've heard your feedback and implemented several features to give you even more granular control over your KKP environment. Now, you can configure audit logging at the Seed level, for deeper visibility across all your User Clusters. For our OpenStack users, KKP 2.28 introduces support for shared routers across user clusters within the same subnet, significantly simplifying your networking setup. Security is always a priority, and you can now further enhance it by defining allowed IP ranges for the API server for user clusters directly at the Seed level. ## Administrative Control and Deprecations KKP 2.28 introduces new options for administrators to fine-tune their KKP deployments. You can now disable default KubeVirt instance types and preferences to control the types of virtual machines that can be provisioned. For environments with stricter security requirements, there's also the option to disable the user SSH key feature throughout KKP. Lastly, please note that with this release, support for the Equinix Metal provider has been deprecated. ## Performance and Network Optimizations We've made backend improvements to boost performance and network efficiency in KKP. You can now fine-tune etcd performance by configuring the backend quota with `etcd quota backend bytes`. **OpenStack users** gain support for multiple `LoadBalancerClasses`, and simplified security group management with the removal of multi-group support. We've also given you more control over your cluster backup schedules with configurable backup interval and count. Data integrity for Velero backups is enhanced with the ability to set a default checksum algorithm. Network routing for user clusters is improved with the option to configure an HTTP proxy, and you can now optimize the performance of the Konnectivity tunnel by configuring Konnectivity Server and Agent channel sizes. ## ​​Have a good time trying out the new features! We're committed to making KKP the best Kubernetes platform for your needs, and this release is a significant step forward. We hope you find these new features and improvements valuable for your projects! Thank you for being a part of the Kubermatic community, and we look forward to your feedback on KKP 2.28. If you find our contributions valuable, we kindly encourage you to leave a star on our [GitHub repository](https://github.com/kubermatic/kubermatic). As always, please don't hesitate to reach out with any questions or suggestions via [Contact Us](/contact-us/) form. --- ## Kubermatic Wins 2025 Digital Innovator Award from Intellyx - **URL:** https://www.kubermatic.com/blog/kubermatic-wins-2025-digital-innovator-award-from-intellyx/ - **Date:** 2026-04-30 - **Description:** Kubermatic wins the 2025 Intellyx Digital Innovator Award for driving enterprise innovation. - **Categories:** Company - **Tags:** Announcements - **Authors:** Sebastian Scheele We have some incredible news to share with our community! We are absolutely thrilled and proud to announce that [Kubermatic has been honored with the 2025 Intellyx Digital Innovator Award](https://intellyx.com/2025/06/11/kubermatic-wins-2025-digital-innovator-award-from-intellyx/) on June 10th 2025. For over a decade, Intellyx has been a leading industry analyst firm dedicated to enterprise digital transformation. They spend their days analyzing the market and identifying the truly trailblazing companies that are driving meaningful change. To be recognized by them is a powerful validation of our mission and the hard work of our entire team. ## Why This Award Means So Much With a strong focus on digital transformation, Intellyx only briefs vendors who are truly disrupting the status quo. This award reinforces the very reason we founded Kubermatic: to radically simplify the complexities of modern infrastructure and empower organizations to innovate faster. > _"At Kubermatic, we're redefining how organizations build, scale, and operate modern infrastructure. Whether it's managing thousands of clusters, simplifying traffic with advanced multi-tenant load balancing, accelerating developer workflows with our Kubernetes-native platform, or building a private cloud — our mission is simple: make Kubernetes effortless, so your teams can focus on what truly matters — innovation,"_ > > _said Kubermatic Co-founder & CEO, Sebastian Scheele._ We want to extend a massive thank you to our incredible team for their dedication and brilliance, to our amazing customers and partners for their trust and collaboration, and to the entire open-source community for constantly inspiring us. This award belongs to all of you, too. To learn more about the award, you can visit the official [2025 Intellyx Digital Innovator awards page](https://intellyx.com/2025/06/10/announcing-the-2025-intellyx-digital-innovator-award-winners/). Explore [our solutions](/#products) and see how we can speed up your journey towards Kubernetes, hybrid and multi cloud. --- ## Why We Need Platform Engineering (and Where DevOps Fell Short) - **URL:** https://www.kubermatic.com/blog/why-we-need-plaform-engineering/ - **Date:** 2026-04-30 - **Description:** This post explores how software development evolved, where DevOps fell short, and why Platform Engineering is the next step. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Csenger Szabo Modern software teams have more tools than ever. Pipelines, configs, dashboards, alerts,... And yet, shipping software still feels... harder than it should be. If you're a developer, you're likely juggling YAML files, CI/CD pipelines, and cloud configs, on top of writing actual code. If you're on a DevOps team, you're probably putting out fires while maintaining an ever-growing stack. And if you're a manager, you've probably seen delivery slow down. Platform Engineering has emerged to tackle all these challenges. This is the opening post in our series "The Journey to Platform Engineering". In this blog, we'll cover how software development has evolved and the persistent challenges that ultimately led to a new approach: Platform Engineering. ## A Quick Look Back at Software Development Not long ago, software was built using the **Waterfall model**: a rigid, step-by-step process where everything had to be planned and completed in order: requirements, design, development, testing, and deployment. It worked when change was rare, but it offered little room to revisit and adjust earlier decisions. This lack of flexibility ultimately led to long development cycles that couldn't keep up with the fast pace of business. Then came **Agile**, introduced in 2001 with the Agile Manifesto. This method led to shorter cycles, constant feedback, and more flexibility. It undeniably helped teams move faster and adapt better. However, Agile didn't fully fix the divide between software development (Dev) and IT operations (Ops). Developers focused on building and delivering features quickly, while Ops prioritized stability and uptime. This misalignment often created friction and slowed the whole development process down. That's where **DevOps** came in. Around 2007-2008, the DevOps movement began to gain traction. It aimed to end these silos and bring more automation, collaboration, and shared responsibility. And it worked! For a while… ## When DevOps Started to Struggle DevOps brought undeniable improvements in terms of increasing collaboration and shared responsibility between development and operations teams. However, as software systems became more complex, DevOps practices started to show their limits. Suddenly, developers were expected to manage everything: infrastructure, deployment, monitoring, security, orchestration, CI/CD, and more. The burden for teams started increasing, and they started spending more time dealing with the pipeline than actually writing software. The idea of "you build it, you run it" was well-intentioned. But, in practice, it overloaded teams with too many tools and tasks. DevOps helped break down silos, but ended up creating new challenges around complexity. ## Enter Platform Engineering Platform Engineering emerged as an evolution of DevOps. Its goal is to make it easy for teams to build software, without forcing them to become experts in every part of the tech stack. It creates a paved path: reusable tools, services, and standards that remove unnecessary complexity from everyday development. Developers don't need to start from scratch every time. They get self-service access to what they need, within a safe and governed framework. This enables teams to focus on building software instead of managing tools and pipelines. Just as importantly, Platform Engineering helps DevOps scale. Instead of every team reinventing the wheel, Platform Engineering brings consistency and reusability across the organization. At its core, Platform Engineering frees teams from unnecessary infrastructure decisions and lets them focus on what they do best: creating. ## Coming Up Next Now that we understand why Platform Engineering was needed, we'll explore what Platform Engineering looks like in practice. In the next blog post, we'll cover how Internal Developer Platforms (IDPs) work and how they help teams stay productive without getting overwhelmed. --- ## Simplify Multi-Cloud Traffic Management with KubeLB - **URL:** https://www.kubermatic.com/resources/simplify-multi-cloud-traffic-management-with-kubelb/ - **Date:** 2025-05-15 - **Description:** In this webinar, we'll cover Kubernetes' inherent load balancing limitations and demonstrate how KubeLB provides a centralized solution to overcome them effectively. # Simplify Multi-Cloud Traffic Management with KubeLB ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Watch our webinar to discover how KubeLB can revolutionize traffic management for your applications Imagine running a dynamic Kubernetes environment, only to hit a roadblock: Kubernetes doesn’t offer a built-in load-balancing solution. While cloud providers offer native options, organizations running on non-cloud infrastructures must rely on external software, leading to fragmented setups that are difficult to manage. Existing solutions often focus on single-cluster environments, adding complexity to multi-cloud and on-prem deployments. The result? Managing load balancing across diverse environments becomes time-consuming and error-prone, with inconsistent performance and a lack of centralized control, ultimately leading to inefficiencies and potential revenue loss. Enter KubeLB, a Kubernetes-native solution simplifying load balancing across multi-cloud, hybrid, and bare-metal environments. It offers consistency, reliability, and seamless scalability. Struggling with complex load balancing in multi-cloud or on-prem Kubernetes setups? Join our live webinar to discover how KubeLB can revolutionize traffic management for your applications. In this webinar, we’ll cover Kubernetes’ inherent load balancing limitations and demonstrate how KubeLB provides a centralized solution to overcome them effectively. What You’ll learn: - The challenges of traditional load balancing in modern infrastructures. - How KubeLB provides a unified, Kubernetes-native solution for Layer 4 (TCP/UDP) and Layer 7 (application) traffic. - Demo: a. Setting up KubeLB management clusters and agents. b. KubeLB Layer 4(TCP/UDP) and Layer 7(Application) load balancing. - Interactive Q&A Session: Get your questions answered by our experts! **Speaker: Waleed Malik, Senior Software Engineer at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Is Europe Breaking Up with US Cloud Giants? - **URL:** https://www.kubermatic.com/blog/is-europe-breaking-up-with-us-cloud-giants/ - **Date:** 2026-04-30 - **Description:** In light of the recent political changes in the US, companies in the EU are starting to look for ways to break free from the giant US cloud providers. But cutting ties won't be easy. - **Categories:** Community, Best Practices - **Tags:** Kubernetes, Open Source Projects - **Authors:** Julian Hansert In light of the recent political changes in the US, companies in the EU are starting to look for ways to break free from the giant US cloud providers. But cutting ties won't be easy. For years, European businesses have relied on American cloud giants - [Amazon Web Services (AWS)](https://aws.amazon.com/), [Microsoft Azure](https://azure.microsoft.com/), and [Google Cloud](https://cloud.google.com/) - to host their data, run applications, and power digital infrastructure. But, as global politics shift and concerns about data privacy rise, many European companies are rethinking their reliance on US tech firms. ## The Growing Call for Digital Sovereignty Under the Trump administration, European businesses and governments have grown increasingly wary of the US government's influence over American tech companies. A key concern is the [CLOUD Act](https://www.cov.com/en/news-and-insights/insights/2018/03/cloud-act-creates-new-framework-for-cross-border-data-access). The Clarifying Lawful Overseas Use of Data (CLOUD) Act allows US authorities to access data stored by American tech firms to investigate serious crimes, even if that data is housed outside of US borders. The government argued it would facilitate cross-border cooperation on criminal investigations. However, the CLOUD Act has triggered fears that sensitive European data could be subject to US legal scrutiny, leading some organizations to explore alternatives closer to home. "There's a huge appetite in Europe to de-risk or decouple from over-dependence on US tech companies," says Marietje Schaake, a nonresident fellow at Stanford's Cyber Policy Center and a former member of the European Parliament. This sentiment was echoed in an [open letter](https://www.the-guild.eu/news-and-blog/news/2025/open-letter-in-support-of-fp10.html) signed by over 100 organizations urging European officials to push for greater technological independence. ## The Shift Toward European Cloud Providers European cloud providers are seizing the opportunity. Companies like OVHcloud, Nextcloud, and Open Telekom Cloud are positioning themselves as viable alternatives to the US hyperscalers. "The motivation to use digitally sovereign providers has shifted," says Falk Weinreich, Managing Director of OVHcloud Germany. "It's no longer just about data protection - it's about the fear of a shutdown from the American side." This concern is not unfounded. A significant percentage of European businesses rely on American cloud providers, meaning any disruption - whether political, regulatory, or technical - could have unpredictable consequences. ## The Challenges of Moving Away from US Clouds Despite the momentum, breaking free from US cloud dominance is easier said than done. The major American providers - Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) - still dominate the global market, holding an estimated 62% share ([Statista, 2025](https://www.statista.com/chart/18819/worldwide-market-share-of-leading-cloud-infrastructure-service-providers/)). While Europe's cloud ecosystem is evolving fast, European providers are still working to match some capabilities - especially large-scale deployments, advanced AI workloads, and global reach. That's why many organizations are taking a pragmatic path: adopting a hybrid cloud strategy that combines both US and European providers. This way, they can spread risk, increase resilience, meet data sovereignty goals, and still benefit from the innovation coming out of the big three. ## The Path Forward While the transition to European cloud providers is still in its early days, it reflects a much bigger conversation around digital sovereignty and infrastructure resilience. In an era of fragile supply chains, it is crucial to remain secure, flexible, and independent. One initiative supporting this shift is [NeoNephos](https://neonephos.org/), a community-driven platform that brings together cloud-native experts, projects, and providers focused on building sovereign cloud infrastructure in Europe. It aims to empower companies, governments, and developers with resources, best practices, and tools to reduce reliance on foreign hyperscalers and foster a more autonomous cloud ecosystem. For companies looking to take back control of their cloud environments - without compromising on performance - solutions like [Kubermatic Virtualization](/products/kubermatic-virtualization/) (KubeV) and [Kubermatic Developer Platform](/products/kubermatic-developer-platform/) (KDP) offer a powerful alternative. With KubeV, organizations can build and manage their own private cloud infrastructure entirely with Kubernetes. It's a strong fit for companies handling sensitive data, offering greater flexibility and helping ease privacy concerns. As Europe's Cloud landscape continues to evolve, businesses will need to think strategically about how they balance security, performance, and independence. And it is clear that the potential break-up with US cloud giants won't happen overnight. It will be gradual, complex, and in many cases, hybrid. But one thing is for sure: the conversation about digital independence is only just beginning. --- ## Comms & Social Media - Why Does a Project Need It - **URL:** https://www.kubermatic.com/resources/comms-social-media-why-does-a-project-need-it/ - **Date:** 2025-04-24 - **Description:** In this session, Mario and Chris share practical strategies for improving communication in open source projects, from social media to critical comms and contributor guidelines. # Comms & Social Media - Why Does a Project Need It ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Mario's and Chris' Talk at KubeCon + CloudNativeCon EU 2025 All the projects have at least a website. Most of the projects try to have some kind of Social Media presence. However, let’s face the hard truth - Comms for a project is hard, and we can run into various pitfalls, and it is a lot of ground to cover. Let’s discover what channels and processes you can employ in a project to ensure good communication. We start with the identification of target groups for comms. What channels to use and will end in drafting social media policies and guidelines for the contributors when they are publishing comms in the name of a project. Also, have you ever thought of critical comms for a project - how do you handle comms if something critical is happening? After the session, you have ideas for your project to move towards a more consistent and reliable communication. **Speakers: Mario Fahlandt, Customer Delivery Architect at Kubermatic & Chris Short (CIQ)** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Keynote: Opening Remarks at Maintainer Summit EU 2025 - **URL:** https://www.kubermatic.com/resources/keynote-opening-remarks-at-maintainer-summit/ - **Date:** 2025-04-25 - **Description:** In this video, Karen, Mario and Natali will introduce the first Maintainer Summit at KubeCon + CloudNativeCon 2025. # Keynote: Opening Remarks at Maintainer Summit EU 2025 ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Karena, Mario, and Natali's Opening Remarks at the Maintainer Summit EU 2025 In this opening keynote, Karena Angell (Red Hat), Mario Fahlandt (Kubermatic), and Natali Vlatko (Cisco) welcome attendees to the first-ever Maintainer Summit at KubeCon + CloudNativeCon EU 2025. They walk us through the purpose and goals of the Maintainer Summit, provide historical context for why it was created, and share what’s on the agenda for the day. From the challenges maintainers face to the importance of creating space for shared learning and collaboration, this session sets the tone for a summit focused on sustainability, support, and community building within the cloud native ecosystem. **Speakers: Mario Fahlandt, Customer Delivery Architect at Kubermatic, Karena Angell (Red Hat) & Natali Vlatko (Cisco)** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Navigating the Inevitable: Kubernetes Breaking Changes Behind the Scenes - **URL:** https://www.kubermatic.com/resources/navigating-the-inevitable-kubernetes-breaking-changes-behind-the-scenes/ - **Date:** 2025-05-08 - **Description:** In this session, Marko unpacks the tough calls behind Kubernetes breaking changes — why they happen, how they're handled, and what you can do as a user to stay informed, give feedback, and support the community. # Navigating the Inevitable: Kubernetes Breaking Changes Behind the Scenes ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Marko Mudrinić's Talk at KubeCon + CloudNativeCon EU 2025 You’re looking forward to a new feature, waiting for the release day like it’s Christmas morning. Suddenly, the feature is dropped from the release. Even worse, a feature you heavily depend on is unexpectedly deprecated or removed. What now? Negative emotions take over, you feel sad, frustrated, and even angry at the project and its maintainers. Fortunately, this doesn’t happen too often. But it does happen. The Kubernetes maintainers strive to make users satisfied, but they also have to prioritize the health of the project and the well-being of the maintainers. To do that, they sometimes have to make breaking changes, even on short notice, as hard as it might be. In this talk, we’ll dive into some of those decisions, see what went on behind the scenes, and talk a bit about Kubernetes policies. Finally, we’ll explore your options as an end user, how you can be better informed, how you can provide feedback on proposed changes, and how you can help the project! **Speakers: Marko Mudrinic, Senior Software Engineer at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Tutorial: Exploring Multi-Tenant Kubernetes APIs and Controllers With Kcp - **URL:** https://www.kubermatic.com/resources/tutorial-exploring-multi-tenant-kubernetes-apis-and-controllers-with-kcp/ - **Date:** 2025-05-08 - **Description:** In this hands-on workshop, participants will learn how to extend Kubernetes with KCP, build APIs, and design controllers to tackle multi-tenancy challenges. # Tutorial: Exploring Multi-Tenant Kubernetes APIs and Controllers With Kcp ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Marko, Robert, Nabarun, Varsha Narsing and Mangirdas' Workshop at KubeCon + CloudNativeCon EU 2025 While Kubernetes transformed container orchestration, creating multi-tenant platforms remains a significant challenge. kcp goes beyond DevOps and workload management, to reimagine how we deliver true SaaS experiences for platform engineers. Think workspaces and multi-tenancy, not namespaces in a singular cluster. Think sharding and horizontal scaling, not overly large and hard to maintain deployments. With novel approaches to well-established building blocks in Kubernetes API-Machinery, this CNCF sandbox project gives engineers a framework to host and consume any kind of API they need to support their platforms. In this hands-on workshop, participants will learn how to extend Kubernetes with KCP, build APIs, and design controllers to tackle multi-tenancy challenges. By exploring real-world scenarios like DBaaS across clusters, attendees will gain practical skills to create scalable, multi-tenant platforms for their Kubernetes environments. **Speakers: Marko Mudrinic, Senior Software Engineer at Kubermatic, Robert Vasek (Clyso), Nabarun Pal (Independent), Varsha Narsing (Red Hat), Mangirdas Judeikis (Cast AI)** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Building a Cloud Native Curriculum for Real-World Readiness - **URL:** https://www.kubermatic.com/resources/building-a-cloud-native-curriculum-for-real-world-readiness/ - **Date:** 2025-05-08 - **Description:** In this session, Marko will share how his team designed a hands-on Cloud Native course that prepares students for industry by teaching DevOps, Kubernetes, CI/CD, and open source. # Building a Cloud Native Curriculum for Real-World Readiness ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Marko Mudrinić's Talk at Cloud Native University Day EU 2025 As Cloud Native technologies become the backbone of modern industry, it’s important to prepare computer science students for the challenges and expectations they’ll face in their careers. Traditional curricula often focus on small, theoretical projects and assignments, while the real world is more about working on large-scale projects, collaborating with diverse teams, and utilizing concepts such as DevOps, none of which students had prior contact with. Marko was part of the team building a Cloud Native curriculum focused on DevOps, Kubernetes, CI/CD, and open source for a 13-week course. The team quickly ran into problems, such as designing assignments big enough to cover these concepts practically. They also discovered that students were not well-versed in Linux, Bash, and working with the CLI. But 13 weeks is a little time to teach all of that. Marko will share how they overcame these problems, and created a course that received very positive feedback from 300+ students. **Speakers: Marko Mudrinić, Senior Software Engineer at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Compare RedHat OpenShift vs. Kubermatic Kubernetes Platform - which is the best Kubernetes Management Platform for Enterprises? - **URL:** https://www.kubermatic.com/resources/compare-redhat-openshift-vs-kubermatic-kubernetes-platform/ - **Date:** 2025-04-30 - **Description:** Which Kubernetes Management Platform is right for you? Let's compare RedHat OpenShift and KKP. # Compare RedHat OpenShift vs. Kubermatic Kubernetes Platform ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Business Case ## Get our comprehensive KKP vs OpenShift comparison When selecting a Kubernetes management platform, enterprises must consider factors such as scalability, hybrid-cloud capabilities, self-service features, multi-cluster management, and integrations with cloud providers. Below, we compare Red Hat OpenShift and Kubermatic Kubernetes Platform (KKP) based on each platform’s key capabilities - so you can choose the best Kubernetes Management Platform that meets your enterprise requirements. ### Why Choose KKP Over OpenShift? KKP is a Kubernetes management platform designed specifically for enterprise customers. It addresses the operational challenges of managing Kubernetes at scale while providing a self-service developer and operations portal. With KKP, organizations benefit from: - **Lightweight Architecture**: KKP is designed to be more lightweight, reducing resource overhead and optimizing performance for a smoother Kubernetes experience. - **Better Workflow and Usability**: KKP offers an intuitive user experience, improving efficiency for both developers and operations teams. - **True Infrastructure Independence**: Unlike OpenShift, KKP is fully infrastructure-agnostic, offering a broader range of cloud and on-premise deployment options. - **Advanced Multi-cloud & Edge Support**: With fully supported edge Kubernetes deployments and extensive cloud provider integrations, KKP surpasses OpenShift in flexibility. ### Key Feature Comparison | Feature | OpenShift | KKP | |-----------------------------------------------------------|-------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------| | **CNCF Certified** | ![Yes](/static/check-mark-icon.svg) | ![Yes](/static/check-mark-icon.svg) | | **Scale** | Supports scaling | Built for large-scale deployments | | **Hybrid-cloud, multi-cloud, and edge environments** | ![Yes](/static/check-mark-icon.svg) | ![Yes](/static/check-mark-icon.svg) | | **Self-service developer and operations portal** | Limited | ![Yes](/static/check-mark-icon.svg) | | **Integration with leading cloud providers** | AWS, Google Cloud, Azure, IBM Cloud, Alibaba Cloud, Oracle Cloud Infrastructure, VMware vSphere | AWS, Google Cloud, Azure, Openstack, VMware vSphere, Open Telekom Cloud, Digital Ocean, Hetzner, Alibaba Cloud, Equinix Metal, Nutanix | | **Dashboard to visualize Kubernetes deployment** | ![Yes](/static/check-mark-icon.svg) | ![Yes](/static/check-mark-icon.svg) | | **K8sGPT & AIKit integration** | ![No](/static/cross-mark-icon.svg) | ![Yes](/static/check-mark-icon.svg) | | **Remote worker nodes** | ![Yes](/static/check-mark-icon.svg) | ![Yes](/static/check-mark-icon.svg) | | **Automated Cluster Lifecycle Management** | ![Yes](/static/check-mark-icon.svg) | ![Yes](/static/check-mark-icon.svg) | | **Multi-cluster Management** | ![Yes](/static/check-mark-icon.svg) | ![Yes](/static/check-mark-icon.svg) | | **Multilanguage Support** | ![Yes](/static/check-mark-icon.svg) | ![Yes](/static/check-mark-icon.svg) | | **MLOps Support** | ![Yes](/static/check-mark-icon.svg) | ![Yes](/static/check-mark-icon.svg) | | **Automated Kubernetes Backup** | ![No](/static/cross-mark-icon.svg)Requires Red Hat Advanced Cluster Management | ![Yes](/static/check-mark-icon.svg) | | **Admin Panel to Manage all users** | ![Yes](/static/check-mark-icon.svg) | ![Yes](/static/check-mark-icon.svg) | | **Kyverno** | ![Yes](/static/check-mark-icon.svg) | ![Yes](/static/check-mark-icon.svg) | | **Creating and Saving Cluster Templates** | Limited | ![Yes](/static/check-mark-icon.svg) | | **Backup and Recovery** | ![Yes](/static/check-mark-icon.svg) | ![Yes](/static/check-mark-icon.svg) | | **Kubernetes Autoscaling** | ![Yes](/static/check-mark-icon.svg) | ![Yes](/static/check-mark-icon.svg) | | **Air-gapped and Offline Deployments** | ![Yes](/static/check-mark-icon.svg) | ![Yes](/static/check-mark-icon.svg) | | **Edge Kubernetes Support** | ![Yes](/static/check-mark-icon.svg) | Fully supported | | **Source-to-image deployment** | ![Yes](/static/check-mark-icon.svg) | ![No](/static/cross-mark-icon.svg) | | **Multi-tenancy and Role-based Access Control (RBAC)** | ![Yes](/static/check-mark-icon.svg) | ![Yes](/static/check-mark-icon.svg)with enhanced flexibility | | **Custom Machine Deployments and Node Auto-provisioning** | ![No](/static/cross-mark-icon.svg) | ![Yes](/static/check-mark-icon.svg) | | **Open-source and Fully Transparent Development** | Source code is open-source but binaries etc. require Subscription | Complete open-source; Additional features via enterprise edition | | **Lightweight and optimized architecture** | ![No](/static/cross-mark-icon.svg) | ![Yes](/static/check-mark-icon.svg) | | **Support / Consulting** | ![Yes](/static/check-mark-icon.svg) | ![Yes](/static/check-mark-icon.svg) | ### Conclusion Choosing the right Kubernetes management platform depends on your enterprise’s needs. While OpenShift provides a robust solution, KKP offers greater flexibility, and a more lightweight experience, making it the preferred choice for enterprises seeking scalable, multi-cloud, and edge-ready Kubernetes deployments. [Get in touch with us!](/demo/) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Dynamic Multi-Cluster Controllers With Controller-runtime - **URL:** https://www.kubermatic.com/resources/dynamic-multi-cluster-controllers-with-controller-runtime/ - **Date:** 2025-05-08 - **Description:** In this session, Marvin Beckers (Kubermatic) and Stefan Schimanski (Upbound) explore how to extend controller-runtime for dynamic multi-cluster management. As Kubernetes shifts towards multi-cluster architectures, maintaining uniform controllers across dynamically changing clusters becomes a challenge. # Dynamic Multi-Cluster Controllers With Controller-runtime ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Marvin's and Stefan's talk at KubeCon + CloudNativeCon EU 2025 In this session, Marvin Beckers (Kubermatic) and Stefan Schimanski (Upbound) explore how to extend controller-runtime for dynamic multi-cluster management. As Kubernetes shifts towards multi-cluster architectures, maintaining uniform controllers across dynamically changing clusters becomes a challenge. This talk covers: - Writing controllers that reconcile resources across multiple clusters - How to build a custom cluster provider to dynamically register clusters - A hands-on example using “kind” clusters and how this can be extended to more complex setups like Cluster API (CAPI) or KCP **Speakers: Marvin Beckers, Team Lead at Kubermatic and Stefan Schimanski (Upbound)** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Contributing To Kubernetes in Its Second Decade - **URL:** https://www.kubermatic.com/resources/contributing-to-kubernetes-in-its-second-decade/ - **Date:** 2025-05-08 - **Description:** In this session from KubeCon 2025, members of the Kubernetes SIG Contributor Experience (ContribEx) team, including Mario Fahlandt from Kubermatic, explore how the Kubernetes contributor experience is evolving as the project enters its second decade. # Contributing To Kubernetes in Its Second Decade ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Nabarun, Mario, Madhav and Priyanka's talk at KubeCon + CloudNativeCon EU 2025 The session covers the journey of new contributors, from onboarding to long-term engagement, and highlights key changes in how the community is structured to ensure contributors not only get started but stick around. The ContribEx team discusses Kubernetes governance, common pitfalls, and the opportunities available for contributors of all backgrounds, whether you’re interested in code or community-facing roles like marketing, events, and content creation. **Speakers: Mario Fahlandt, Customer Delivery Architect at Kubermatic, Nabarun Pal, Madhav Jivrajani (UIUC), Priyanka Saggu (SUSE)** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Meet KubeOne 1.10 - Supporting Kubernetes 1.32 - **URL:** https://www.kubermatic.com/blog/meet-kubeone-1-10-supporting-kubernetes-1-32/ - **Date:** 2026-04-30 - **Description:** The KubeOne 1.10 release introduces support for Kubernetes 1.32, Fish shell completion, KubeVirt CSI driver deployment, and OCI Helm charts. - **Categories:** Products - **Tags:** KubeOne - **Authors:** Artiom Diomin We're happy to announce that KubeOne 1.10 is now available! KubeOne is our open-source cluster lifecycle management tool which automates cluster deployment and management in your preferred on-prem, edge, or cloud environment. This update focused on essential improvements rather than wide changes, but we've introduced key improvements to enhance usability and flexibility. Here's what's new in KubeOne 1.10: **Support for Kubernetes 1.32**: Keeping up with the latest Kubernetes versions is always a priority for us. With KubeOne 1.10, we now support Kubernetes 1.32, ensuring you can take advantage of the newest performance improvements. As part of this update, all components deployed by KubeOne, including CNIs and other add-ons, have been updated to their latest versions. **Support for Fish Shell Completion**: KubeOne 1.10 introduces support for Fish shell completion, making command-line interactions even more seamless. If you're a Fish shell user, you can now enjoy intuitive autocompletion when working with KubeOne, reducing the chance of errors. ``` kubeone completion fish > ~/.config/fish/completions/kubeone.fish ``` **Deployment of KubeVirt CSI Driver**: For users leveraging KubeVirt, this release brings support for deploying the KubeVirt CSI driver. This addition streamlines storage management within virtualized Kubernetes environments, making it easier to handle persistent storage for KubeVirt workloads. **Allow OCI Helm Charts Deployment**: With KubeOne 1.10, we're making it easier than ever to deploy Helm charts from OCI (Open Container Initiative) registries. This update allows users to pull Helm charts directly from OCI-compliant repositories, expanding deployment options and improving workflow flexibility. We hope [KubeOne 1.10](https://github.com/kubermatic/kubeone) helps you manage your Kubernetes clusters with greater ease! For more details, check out the [changelog](https://github.com/kubermatic/kubeone/tree/main/CHANGELOG) and upgrade instructions. As always, we'd love to hear your feedback. Reach out to us on our {{< slackjoinlink "Community Slack" >}} or on [Github](https://github.com/kubermatic/kubeone)! --- ## Live from KubeCon 2025 with Liz Rice - **URL:** https://www.kubermatic.com/resources/live-from-kubecon-2025-with-liz-rice/ - **Date:** 2025-04-23 - **Description:** We caught up with Liz Rice at the biggest KubeCon ever - 12,500+ people and still buzzing on a Friday afternoon! Anthony Hodson, from Kubermatic, chats with Liz Rice from Isovalent, about what stood out this year: from real-world Kubernetes adoption stories to the growing focus on business and leadership tracks. # Live from KubeCon 2025 with Liz Rice ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Liz Rice's interview with Anthony Hodson at KubeCon + CloudNativeCon EU 2025 We caught up with Liz Rice at the biggest KubeCon ever - 12,500+ people and still buzzing on a Friday afternoon! Anthony Hodson, from Kubermatic, chats with Liz Rice from Isovalent, about what stood out this year: from real-world Kubernetes adoption stories to the growing focus on business and leadership tracks. **Speakers: Anthony Hodson, UK Technical Sales at Kubermatic with Liz Rice (Isovalent)** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Making Kubernetes Enterprise Ready - Panel Discussion at KubeCon - **URL:** https://www.kubermatic.com/resources/making-kubernetes-enterprise-ready-panel-discussion-at-kubecon/ - **Date:** 2025-04-23 - **Description:** In this Panel Discussion at KubeCon London 2025, platform owners will understand what's needed to move Kubernetes into primetime in an organisation. # Making Kubernetes Enterprise Ready - Panel Discussion at KubeCon ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch this panel discussion at KubeCon + CloudNativeCon EU 2025 In this Panel Discussion at KubeCon London 2025, platform owners will understand what’s needed to move Kubernetes into primetime in an organisation. **Speakers**: Liz Rice @ Isovalent (Networking & Observability) Tobias Gerhardt @ Aqua Security (Threat Detection and Remediation) Andy Gower @ Portworx by Pure Storage (Cloud Native Enterprise Storage) Julian Hansert @ Kubermatic (Multi Cluster Management) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Building a Collaborative Machine Learning Model for Drug Discovery - **URL:** https://www.kubermatic.com/resources/building-a-collaborative-machine-learning-model-for-drug-discovery/ - **Date:** 2025-04-10 - **Description:** The MELLODDY project successfully used federated machine learning to train ML and AI models for pharmaceutical companies. # Building a Collaborative Machine Learning Model for Drug Discovery ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Business Case MELLODDY was a European-funded initiative designed to solve a long-standing challenge: how can pharmaceutical companies improve machine learning (ML) models for drug discovery without exposing sensitive data? The project brought together 10 leading pharma companies — including [Bayer](https://www.bayer.com/en/), [GSK](https://www.gsk.com/en-gb/), and [Novartis](https://www.novartis.com/) — alongside key technical partners like [NVIDIA](https://www.nvidia.com/en-eu/), [BME-HIT](https://www.hit.bme.hu/), [Owkin](https://www.owkin.com/), [KU Leuven](https://www.kuleuven.be/english/kuleuven), the [Substra Foundation](https://www.labelia.org/), and [Kubermatic](/). Together, they developed the first industry-scale federated learning platform for drug discovery, enabling companies to train ML models collaboratively while keeping proprietary data confidential. Using federated learning, MELLODDY aggregated training updates — rather than raw data — from each partner after every iteration. This approach ensured data privacy while simultaneously developing more accurate predictive models. In fact, the global predictive model that resulted from this project outperformed all of the single partner models. Kubermatic played a key role by providing the scalable Kubernetes infrastructure that allowed each pharma partner to run the platform securely on Amazon Web Services (AWS). MELLODDY has set a new industry standard for AI-driven drug discovery. With the developments from this project, pharma companies will now be able to cooperate in training ML models, without compromising confidentiality — enabling a faster drug discovery process. MELLODDY has set a new industry standard for AI-driven drug discovery. With the developments from this project, pharma companies will now be able to cooperate in training ML models, without compromising confidentiality — enabling a faster drug discovery process. ![colorful pills](/static/building-a-collaborative-machine-learning-model-for-drug-discovery-1150x647.jpg) *colorful pills* ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Enabling Secure Pharma Cooperation with Federated ML - **URL:** https://www.kubermatic.com/customers/enabling-secure-pharma-cooperation-with-federated-ml/ - **Date:** 2026-06-23 - **Description:** Discover how MELLODDY leveraged federated machine learning to revolutionize drug discovery using AI and ML predictive models. # Enabling Secure Pharma Cooperation with Federated AI ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## The Challenge ### Enabling Collaboration in Drug Discovery While Protecting Proprietary Data The pharmaceutical industry faced a critical challenge: improving machine learning (ML) models for drug discovery while maintaining the confidentiality of proprietary datasets. Traditionally, pharma companies developed ML models in isolation due to concerns over data privacy and intellectual property protection. However, this approach resulted in suboptimal models, as ML models improve with larger and more diverse datasets. In other words, pharmaceutical companies could achieve better results by training ML models on combined data. Yet, companies feared exposing sensitive information to their competitors - preventing collaboration and slowing down scientific progress. The MELLODDY (Machine Learning Ledger Orchestration for Drug Discovery) project aimed to break this impasse by enabling 10 leading pharmaceutical companies - including Bayer, GSK, and Novartis - to collaboratively train ML models without sharing raw data. ## The Solution ### "Coopetition" The MELLODDY team turned to federated learning, an approach that allows ML models to learn from multiple datasets without ever transferring raw data. Instead of pooling sensitive information in a central database, each company kept its data within its own secure environment. In this project, models were trained on distributed data across companies without centralizing it, creating a new form of “coopetition”. [The Kubermatic Kubernetes Platform (KKP)](/products/kubermatic-kubernetes-platform/) was used to build the scalable Kubernetes infrastructure for each pharma partner. This infrastructure enabled partners to register and use their proprietary datasets locally, allowing private models to learn from the combined knowledge without sharing sensitive data. For the first time, competing pharmaceutical companies could collaborate on their research without compromising security. ## The Impact ### Paving the way for data-sharing in Pharma MELLODDY proved that pharma companies don’t have to choose between privacy and progress. By working together under a federated learning framework, they built better predictive models that outperformed every single partner model. Therefore, the MELLODDY project has created a viable solution for pharma companies to cooperate in developing better machine-learning models. This project set the stage for a future where AI-driven breakthroughs can happen faster - resulting in more accurate models and faster drug development. ![Pharmaceutical expert interacting with technology](/static/pharmaceutical-expert-interacting-with-technology-bg.jpg) ![MELLODDY white logo](/static/melloddy-white.png) MELLODDY was a European Innovative Medicines Initiative (IMI) that gathered 10 pharmaceutical companies, academic research labs, large industrial companies, and startups, including Bayer, GSK, Novartis and Kubermatic. The MELLODDY (Machine Learning Ledger Orchestration for Drug Discovery) platform was the first industry-scale platform to enable the creation of a global federated model for drug discovery without sharing the confidential data sets of individual partners. It was a groundbreaking project that allowed Machine Learning models to be trained with data from several pharmaceutical partners, maintaining the confidentiality of the data. > The MELLODDY project is a groundbreaking collaboration that has the potential to accelerate drug discovery and improve patient outcomes by enabling, for the first time, research to be conducted across the consortium's decentralised and highly proprietary databases of annotated chemical libraries. This project allows the pharma partners for the first time to collaborate in their core competitive space, invigorating discovery efforts through efficiency gains. Hugo Ceulemans, Project Leader, Janssen Pharmaceutica NV --- ## MELLODDY: Turning Pharma Competition into "Coopetition" - **URL:** https://www.kubermatic.com/blog/melloddy-turning-pharma-competition-into-coopetition/ - **Date:** 2026-04-30 - **Description:** Discover how MELLODDY leveraged federated machine learning to revolutionize drug discovery using AI and ML predictive models. - **Categories:** Company, Products - **Tags:** KKP, Announcements - **Authors:** Akash Gautam In economics, the prisoner's dilemma describes a paradox where all players in the game would benefit from collaboration. Yet, they decide not to do so and settle for a suboptimal outcome due to a lack of trust in each other - ultimately leading to a worse outcome for everyone. This was exactly the challenge pharmaceutical companies faced when developing machine learning (ML) models for drug discovery. Machine Learning (ML) and Artificial Intelligence (AI) models require large amounts of data to be trained on - and their accuracy increases as more high-quality datasets are fed into the model. If pharma companies could combine their datasets, they could build more powerful predictive models, leading to faster scientific breakthroughs in drug development. However, they faced two major obstacles: data privacy and competition concerns. Not only were companies wary of sharing their proprietary data with competitors, but there were also potential regulatory challenges involved. As a result, they developed their models in isolation. The solution: MELLODDY The MELODDY project (Machine Learning Ledger Orchestration for Drug Discovery) was created to tackle these challenges. As a European-funded project, MELLODDY brought together 10 leading pharma companies - including [Bayer](https://www.bayer.com/en/), [GSK](https://www.gsk.com/en-gb/), and [Novartis](https://www.novartis.com/) - alongside key technical partners like [NVIDIA](https://www.nvidia.com/en-eu/), [BME-HIT](https://www.hit.bme.hu/), [Owkin](https://www.owkin.com/), [KU Leuven](https://www.kuleuven.be/english/kuleuven), the [Substra Foundation](https://www.labelia.org/), and [Kubermatic](/). The goal? Train ML models collaboratively - without ever sharing raw data. ### How it worked MELLODDY used federated learning, a technique that allows models to learn from distributed data while keeping it private. Instead of pooling raw data in a central location, each partner trained the model locally, and only encrypted training updates (gradients) were shared with the global model. This ensured that no confidential data was ever exposed. Kubermatic played a key role in providing the scalable Kubernetes infrastructure for each pharma partner, based on the [Kubermatic Kubernetes Platform](/products/kubermatic-kubernetes-platform/) (KKP). The platform was deployed on [Amazon Web Services (AWS)](https://aws.amazon.com/) multi-account architecture, and it allowed companies to run Kubernetes clusters in private subnets. ### The Impact MELLODDY successfully created the first industry-scale federated learning platform for drug discovery. This breakthrough project resulted in a global model that outperformed any individual company's ML models. It proved that pharma companies can work together without compromising their data. In the end, everyone won - MELLODDY broke free from the prisoner's dilemma, turning competition into "coopetition". And the biggest winner? Society, which will benefit from faster, more efficient drug discovery in the years to come. To learn more about the MELLODDY project, explore the [project report](https://arxiv.org/pdf/2210.08871) or [this article](https://pubs.acs.org/doi/10.1021/acs.jcim.3c00799). Get in touch with us! [Book a demo](/demo/) or [learn more about KKP](/products/kubermatic-kubernetes-platform/). --- ## KubeCon London 2025 - Diary 2 | A conversation with Kubermatic - **URL:** https://www.kubermatic.com/resources/kubecon-london-2025-diary-2-a-conversation-with-kubermatic/ - **Date:** 2025-07-01 - **Description:** Learn more about the Kubernetes Developer Platform featuring Marvin Beckers at KubeCon London. # KubeCon London 2025 - Diary 2 | A conversation with Kubermatic ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Marvin Beckers' interview for the Cloud Native Podcast In this episode of the Cloud Native Podcast, Marvin Beckers discusses the development of a Kubernetes Developer platform that centralizes multi-cluster management for maintaining consistent policies across diverse environments. Marvin shares what the Kubermatic team has been working on recently, explores key features of the Kubermatic Developer Platform, and highlights their exciting involvement in the KCP project, now part of the CNCF Sandbox. This episode was recorded live at KubeCon London 2025. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## FoDO on Tour: KubeCon EU 2025 SPECIAL - **URL:** https://www.kubermatic.com/resources/fodo-on-tour-kubecon-eu-2025-special/ - **Date:** 2025-04-07 - **Description:** This is a special German-language episode recorded live at KubeCon EU 2025! We explore topics like digital sovereignty, Kubernetes Cluster Platform (KCP), Agentic Platform Engineering and more. # FoDO on Tour: KubeCon EU 2025 SPECIAL ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ![](/static/fodo-on-tour-kubecon-eu-2025-special_hu_1cd3f122e8872458.png) Podcast This is a special German-language episode recorded live at KubeCon EU 2025! We explore topics like digital sovereignty, Kubernetes Cluster Platform (KCP), Agentic Platform Engineering and more. [Listen](https://focusondevops.podigee.io/123-new-episode) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Kyverno Chronicles: A DevSecOps Tale - **URL:** https://www.kubermatic.com/resources/kyverno-chronicles-a-devsecops-tale/ - **Date:** 2025-04-23 - **Description:** In this session at Cloud Native Rejekts, Koray Oksay, from Kubermatic, explores how Kyverno brings policy management to Kubernetes. This talk breaks down its role in admission control, security, and automation within your clusters. # Kyverno Chronicles: A DevSecOps Tale ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Koray Oksay's talk at Cloud Native Rejekts 2025 In this session at Cloud Native Rejekts, Koray Oksay, from Kubermatic, explores how Kyverno brings policy management to Kubernetes. This talk breaks down its role in admission control, security, and automation within your clusters. **Speaker: Koray Oksay, Kubernetes Consultant at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Evaluating Global Load Balancing Options for Kubernetes in Practice - **URL:** https://www.kubermatic.com/resources/evaluating-global-load-balancing-options-for-kubernetes-in-practice/ - **Date:** 2025-04-23 - **Description:** In this talk at Cloud Native Rejekts, Nicolai Ort and Tobias Schneck will take you through the real-world lessons learned while evaluating global load-balancing solutions for Kubernetes. # Evaluating Global Load Balancing Options for Kubernetes in Practice ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Nicolai Ort's and Tobias Schneck's talk at Cloud Native Rejekts 2025 In this talk at Cloud Native Rejekts, Nicolai Ort and Tobias Schneck will take you through the real-world lessons learned while evaluating global load-balancing solutions for Kubernetes. **Speakers: Tobias Schneck, Principal Software Architect at Kubermatic with Nicolai Ort (DATEV)** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## 5 Crucial Benefits of Internal Developer Platforms (IDPs) - **URL:** https://www.kubermatic.com/blog/5-crucial-benefits-of-internal-developer-platforms/ - **Date:** 2026-04-30 - **Description:** Learn why IDPs are becoming essential for modern software teams. Discover how Internal Developer Platforms (IDPs) boost developer productivity, streamline operations, reduce errors, and accelerate time to market. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Sebastian Scheele Nowadays, developers face a paradox: while technology advances rapidly, the complexity of managing infrastructure slows them down. Internal Developer Platforms (IDPs) solve this challenge by streamlining workflows, reducing cognitive load, and enhancing productivity. IDPs are increasingly recognized as essential tools for organizations aiming to increase developer productivity. According to [Gartner](https://www.gartner.com/en/infrastructure-and-it-operations-leaders/topics/platform-engineering), by 2026, 80% of large software engineering organizations will establish platform engineering teams as internal providers of reusable services, components, and tools for application delivery - up from 45% in 2022. IDPs integrate tools, services, and processes within a unified environment, empowering developers to manage applications autonomously, and reducing reliance on operations teams. In this article, we'll explore the significant benefits of implementing IDPs, supported by industry statistics. ## 1. Boosting Developer Productivity and Reducing Developer Burden IDPs significantly reduce the time and effort required to manage infrastructure by automating routine tasks, such as service instance creation and configuration. This automation improves productivity and frees up developers to focus on strategic initiatives. Additionally, IDPs significantly reduce the cognitive load for developers, by providing a unified service catalog that integrates several tools and processes into a single interface. This centralization simplifies the development process and reduces the mental strain for developers, as they no longer need to switch between different tools and environments. Consequently, developer experience is improved - which is strongly connected to productivity. According to <a href="/static/Humanitec-Forrester-Opportunity-Snapshot-Platform-Engineering.pdf" target="_blank">Forrester</a>, 74% of companies that improve their developer experience (DevEx) report increased productivity. ## 2. Elevating Operational Efficiency IDPs are powerful tools to streamline and standardize operations. IDPs integrate key infrastructure components, such as CI/CD pipelines, monitoring, security, and cloud resources, into a single platform. This centralized platform creates a seamless operational interface that reduces bottlenecks and optimizes workflows. Moreover, IDPs enable self-service tooling for developers, reducing their reliance on Operations, and improving collaboration across teams. As a result, cross-team communication and coordination improve, leading to more effective teamwork and increased productivity. ## 3. Scaling with Confidence: Reducing Errors with IDPs Internal Developer Platforms (IDPs) significantly boost scalability and minimize errors by standardizing environments and automating deployments. By providing consistent configurations across development and production, IDPs help eliminate discrepancies and reduce the likelihood of errors. The automation implemented by IDPs also eliminates manual deployment mistakes and facilitates scaling, by enabling applications to support varying workloads. According to the <a href="/static/DevOps-Benchmarking-Study-2023.pdf" target="_blank">DevOps Benchmarking Study 2023</a>, 89% of companies using an IDP report a change failure rate below 15%, compared to 75% without an IDP. Furthermore, the DORA 2023 State of DevOps report reveals that after adopting Platform Engineering, 60% of enterprises saw improvements in system reliability. ## 4. Increased Deployment Frequency and Faster Time to Market By automating and streamlining the deployment process, IDPs significantly increase deployment frequency and accelerate time to market. With IDPs, 71% of teams can deploy applications on-demand or several times per day, a substantial increase compared to only 43% without IDPs (DevOps benchmarking study 2023). This improvement is possible due to automated pipelines and standardized processes that are implemented through IDPs. By minimizing errors and ensuring consistent environments across development and production, IDPs eliminate bottlenecks, and allow teams to quickly roll out new features and updates. As a result, organizations can respond faster to market demands and deliver innovations more rapidly. ## 5. Increased Security and Compliance One further advantage worth mentioning from IDPs is security and compliance improvements. The automation implemented by an IDP makes platforms less fragile and more secure, as it allows to rapidly identify vulnerabilities and fragilities. Built-in features like role-based access control, automated updates, and policy enforcement ensure consistent application of security protocols, minimizing human error and unauthorized access. By automating compliance checks, IDPs help organizations adhere to industry standards and regulations. ## Conclusion In summary, Internal Developer Platforms are crucial for modernizing and optimizing the software development lifecycle. They significantly improve productivity, operational efficiency, and cross-team collaboration, while reducing lead times and failure rates. With organizations reporting tangible benefits such as improved customer satisfaction, improved developer satisfaction, and revenue growth, IDPs are reshaping how businesses approach application development and deployment. In my view, IDPs are more than tools - they are catalysts that will transform how developers work. IDPs are the key to free developers to do what they do best: creating. --- ## Maximize your developers' productivity and accelerate innovation with Kubermatic Developer Platform - **URL:** https://www.kubermatic.com/solution-brief-empower-developers-and-accelerate-innovation-with-kubermatic-developer-platform/ - **Date:** 2025-11-05 - **Description:** KDP empowers organizations to maximize developer productivity, reduce operational costs, and accelerate innovation. # Empower Developers and Accelerate Innovation with Kubermatic Developer Platform ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Introduction Maximize your developers’ productivity and accelerate innovation with Kubermatic Developer Platform (KDP). Powered by Kubernetes API and based on [CNCF Sandbox project KCP](https://www.cncf.io/projects/kcp/), Kubermatic’s cutting-edge internal developer platform enables the seamless creation and management of services backed by a centralized catalog. With unparalleled multi-tenancy, development teams can access and instantly deploy services, taking collaboration and efficiency to new heights. ## Key Benefits ### Cost Savings and Efficiency By automating the service instance creation process, KDP eliminates the need for manual ticketing systems, saving developers and platform owners valuable time and leading to significant cost reductions. ### Greater Developer Productivity With near-instant service deployment and management, KDP allows developers to focus on writing code and driving innovation rather than waiting for service instances to be manually created. ### Streamlined Development Operations IDPs are designed to scale with the organization’s needs, whether managing a few services or thousands. The flexibility of IDPs allows organizations to tailor the platform to their specific needs, ensuring that it can adapt to changing business requirements. ### Unrivaled Multi-Tenancy Empower multiple teams or organizations to operate on the same platform with fully isolated resources, user permissions, and secure environments. ### Accelerated Innovation By offering a comprehensive service catalog easily accessible across the organization, KDP enables seamless collaboration, giving developers more time and freedom to innovate. ### Tailored Integration and Customization KDP goes beyond convenience; its highly customizable platform adapts to your organization’s unique needs to fit your internal culture, policies, and governance structure, ensuring seamless integration into your existing workflows. ### Future-Proof Scalability KDP’s ability to integrate with existing operators and tools like Crossplane ensures that the platform meets current needs and is scalable and adaptable for future growth and challenges. ## Save Time and End Bottlenecks Manual ticketing and service management processes can create significant bottlenecks, leading to developer downtime, inconsistent results, and unnecessary costs. KDP provides a transformative solution by automating these processes, centralizing service management, and enhancing operational efficiency. Whether you’re a large enterprise with multiple IT teams or a startup with a complex IT infrastructure, KDP is designed to streamline your operations and drive innovation. ## Powered by Kubernetes APIs KDP uniquely leverages Kubernetes APIs to seamlessly integrate with existing cloud-native environments, providing consistent service management across your organization. Its robust multi-tenancy and modularity allow service managers and platform owners to effortlessly add and manage new services, streamlining operations and enhancing collaboration, ultimately positioning your organization for sustained growth and success. ## Key Features ![](/static/clock-gold-pink.svg) ### Automated One-Click Service Instance Creation Near-zero wait time for new instances. ![](/static/transformation-icon-gold-pink.svg) ### Self-Service Provisioning Multi-tenant dashboard or API enables self-service driven provisioning, enhancing flexibility and autonomy for teams. ![](/static/ui-panel-icon-gold-pink.svg) ### Unified Services A centralized platform with a comprehensive Service Catalog provides company-wide visibility. ![](/static/cloud-icon-gold-pink.svg) ### First Cloud-Native Service Catalog Supports multi-cluster, multi-cloud environments and integrates both cloud-native and non-cloud-native services. ![](/static/wheel-icon-gold-pink.svg) ### Unmatched Multi-Tenancy Multiple development teams can securely access and deploy services instantly, with complete separation between environments. ![](/static/gear-icon-pink-grad.svg) ### Customizable Platforms Tailored to fit the organization's specific needs. ![](/static/wrench-icon-gold-pink.svg) ### Adaptable to Culture and Policies Aligns with internal governance and structure. ![](/static/consistency-icon-gold-pink.svg) ### Native Kubernetes APIs Seamless integration of existing operators and Crossplane into the platform. ![](/static/scheme-icon-pink-grad.svg) ### Integration with Any Kubernetes Cluster Effortlessly integrates into any Kubernetes cluster for greater flexibility. ![](/static/centralized-icon-gold-pink.svg) ### Build Your Managed Service Portfolio Platform designed to create and manage internal or external service portfolios with ease. ![](/static/cash-gold-pink.svg) ### Service-Based Cost Metering Future releases will offer service-based cost tracking for optimized resource management. ## Maximize Productivity and Reduce Costs KDP empowers organizations to maximize developer productivity, reduce operational costs, and accelerate innovation. By providing a centralized, easily accessible platform, KDP ensures that all teams have the tools they need to innovate faster and more effectively. ## Get Started Today KDP is easy to implement and customize to fit your organization’s specific needs. To learn more about how KDP can transform your service management and development operations, contact us today for a demonstration or to speak with a representative. [Talk to Us Now!](/demo/) ## Other Resources [CNCF KCP Project](https://www.cncf.io/projects/kcp/) [Podcast on CNCF (eng) project KCP by Marvin Beckers, Kubermatic.](https://kubernetespodcast.com/episode/238-kcp/) [Podcast on CNCF (de) project KCP by Marvin Beckers, Kubermatic.](https://focusondevops.podigee.io/109-container-days-2024-kcp) [CNCF Platforms White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/) [Kubermatic Developer Platform (KDP) Whitepaper](/whitepaper-kdp-empower-developers-accelerate-innovation/) --- ## Empower developers and accelerate innovation with KDP - **URL:** https://www.kubermatic.com/whitepaper-kdp-empower-developers-accelerate-innovation/ - **Date:** 2026-03-23 - **Description:** Empower your developers and accelerate innovation with Kubermatic Developer Platform (KDP) – enabling self-service, automation, and seamless Kubernetes management at scale. # Kubermatic Developer Platform (KDP) Empower Developers and Accelerate Innovation ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Introduction Internal Developer Platforms (IDPs) have emerged as a critical tool for organizations aiming to enhance developer productivity, streamline operations, and foster innovation. These platforms provide a unified environment where developers can easily access and deploy services, enabling faster time-to-market and reducing the complexity of managing infrastructure. IDPs are particularly beneficial to three key roles within an organization: ![](/static/kdp-illustration-1.svg) ### Service Owners Provide and operate value adding services. Responsible for providing and operating value-adding services, service owners benefit from IDPs by having a centralized platform that simplifies service management, reduces manual processes, and ensures consistency across deployments. ![](/static/kdp-illustration-2.svg) ### Platform Teams Keeps the platform running and onboards users. Tasked with keeping the platform running and onboarding users, platform teams leverage IDPs to automate workflows, improve scalability, and ensure that the underlying infrastructure is abstracted in a way that is accessible and usable by developers. ![](/static/kdp-illustration-3.svg) ### Developers Consume services to deploy business apps. As the primary consumers of the services provided by the platform, developers gain significant advantages from IDPs by having immediate access to the resources they need to build and deploy applications, reducing downtime and allowing them to focus on innovation. The Kubermatic Developer Platform (KDP) is a next-generation IDP that leverages Kubernetes APIs to offer a robust, scalable, and customizable solution designed to meet the unique needs of organizations of all sizes. ## The Value of Internal Developer Platforms IDPs are designed to abstract the complexities of infrastructure management, providing developers with a simplified, self-service interface for deploying and managing applications. This abstraction is crucial in today’s fast-paced development environments, where the ability to quickly and efficiently deploy services can provide a significant competitive advantage. ### Key benefits of IDPs include ![](/static/ui-panel-icon-white.svg) ### Centralized Service Management IDPs provide a unified service catalog, giving developers and platform teams a single control point for managing and deploying services. This centralization reduces the risk of inconsistencies and errors, improves collaboration, and enhances operational efficiency. ![](/static/consistency-icon-white.svg) ### Automation and Efficiency IDPs significantly reduce the time and effort required to manage infrastructure by automating routine tasks such as service instance creation and configuration. This automation improves productivity and frees up resources that can be redirected toward more strategic initiatives. ![](/static/refresh-icon-white.svg) ### Scalability and Flexibility IDPs are designed to scale with the organization’s needs, whether managing a few services or thousands. The flexibility of IDPs allows organizations to tailor the platform to their specific needs, ensuring that it can adapt to changing business requirements. ## Kubermatic Developer Platform (KDP) The Kubermatic Developer Platform (KDP) is a cutting-edge internal developer platform that builds on the strengths of Kubernetes and the [CNCF Sandbox project KCP](https://www.cncf.io/projects/kcp/). KDP offers a comprehensive solution that integrates seamlessly into existing workflows, providing a unified platform for managing and deploying services across the organization. ### Kubernetes-Powered At its core, KDP leverages the power of Kubernetes APIs, enabling the platform to provide seamless integration with cloud-native environments. This integration ensures that KDP can support many use cases, from small startups to large enterprises with complex IT infrastructures. ### Multi-Tenancy and Modularity KDP offers unparalleled multi-tenancy, allowing organizations to securely isolate and manage multiple teams or departments within the same platform. Its modular design allows for easy customization, enabling organizations to tailor the platform to their needs and integrate existing tools and services. ### Centralized Service Catalog KDP includes a centralized service catalog that provides a unified view of all available services within the organization. This catalog is easily accessible by development teams, enabling them to quickly identify and deploy the needed services without the delays associated with traditional ticketing systems. ## Key Features ![](/static/grad-box.svg) ### Commercial Distribution Based on upstream kcp with “batteries included” by Kubermatic. ![](/static/grad-planet-rocket.svg) ### Native Kubernetes APIs Easily intergrate existing operators and Crossplane into the platform. ![](/static/grad-cubes.svg) ### Highly Customizable Adjusts to your organisation structure and requirements. ### Automated Service Instance Creation KDP automates the process of service instance creation, reducing the time required to deploy new services from hours or days to mere seconds. This automation eliminates the need for manual intervention, reducing the risk of errors and improving overall efficiency. ### Customizable Platform KDP is highly customizable, allowing organizations to tailor the platform to fit their internal culture, policies, and governance structures. This flexibility ensures that KDP integrates seamlessly into existing workflows, providing all users a consistent and reliable experience. ### Seamless Integration with Kubernetes APIs KDP’s use of Kubernetes APIs ensures the platform can integrate seamlessly with existing cloud-native infrastructures, providing a consistent and reliable service management experience across all environments. ### Service Management Flexibility The platform’s modularity allows service owners and platform teams to easily add new services, ensuring the platform can adapt to the organization’s evolving needs. This flexibility is particularly beneficial in fast-paced development environments where the ability to deploy new services quickly can provide a significant competitive advantage. ## Technical Benefits ### Efficiency Gains By automating service deployment and management, KDP significantly reduces the time and resources required to manage IT infrastructures. This efficiency translates into cost savings and allows development teams to focus on innovation rather than administrative tasks. ### Improved Collaboration KDP’s centralized service catalog enhances collaboration across development teams by providing a unified platform for service management. This centralization reduces communication barriers and ensures all teams can access the necessary tools and services. ### Unmatched Multi-Tenancy KDP allows multiple development teams to securely access and deploy services in isolated environments. Each team operates independently and separately, ensuring security, compliance, and operational efficiency across the organization. ### Reduced Downtime KDP’s automation capabilities minimize downtime by ensuring that services are deployed quickly and correctly. This reliability is crucial for organizations that rely on continuous service availability to support their operations. ### Enhanced Innovation By freeing up resources and reducing the time spent on manual tasks, KDP enables development teams to focus on innovative projects that drive business growth. The platform’s flexibility and scalability also ensure that it can support new initiatives. ## Use Cases ![](/static/rocket-icon-white.svg) ### Enterprise IT Management Large enterprises with multiple IT teams can use KDP to centralize and streamline their service management processes, ensuring all teams have access to the necessary resources while maintaining security and compliance. ![](/static/robot-white-img.svg) ### Tech Startup Ecosystems Startups with limited IT resources can leverage KDP to automate service deployment and management, allowing them to focus on product development and innovation without the burden of managing complex infrastructures. ![](/static/gear-icon-white.svg) ### Cloud-Native Development Organizations transitioning to cloud-native architectures can use KDP to manage their containerized services efficiently, ensuring they can scale their operations while maintaining control over their IT environments. ## Conclusion **The Kubermatic Developer Platform (KDP) represents a significant advancement in service management technology. By leveraging the power of Kubernetes APIs and the flexibility of the CNCF Sandbox project KCP, KDP provides a robust, scalable, and customizable platform that meets the needs of organizations of all sizes. With its automation capabilities, centralized service catalog, and multi-tenancy features, KDP streamlines service deployment and management, reducing costs, improving collaboration, and enabling innovation. As organizations evolve and grow, KDP stands ready to support their journey, providing a future-proof solution for managing complex IT environments**. ![](/static/night-city-road.png) ## About Kubermatic Kubermatic is a leader in Kubernetes and cloud-native technologies, dedicated to empowering organizations with advanced solutions that simplify and optimize IT management. Our products are designed to meet the needs of modern enterprises, providing the tools and support necessary to drive innovation and achieve business success. For more information about KDP and other Kubermatic solutions, please visit our website or contact our sales team. ## Other Resources [CNCF KCP Project](https://www.cncf.io/projects/kcp/) [Podcast on CNCF (eng) project KCP by Marvin Beckers, Kubermatic.](https://kubernetespodcast.com/episode/238-kcp/) [Podcast on CNCF (de) project KCP by Marvin Beckers, Kubermatic.](https://focusondevops.podigee.io/109-container-days-2024-kcp) [CNCF Platforms White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/) [Kubermatic Developer Platform (KDP) Solution Brief](/solution-brief-empower-developers-and-accelerate-innovation-with-kubermatic-developer-platform/) --- ## Simplifying Kubernetes Adoption Challenges with Koray Oksay - **URL:** https://www.kubermatic.com/resources/simplifying-kubernetes-adoption-challenges-with-koray-oksay/ - **Date:** 2025-03-24 - **Description:** Discover the most common challenges in implementing Kubernetes and how to overcome them! # Simplifying Kubernetes Adoption Challenges with Koray Oksay ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ![](/static/simplifying-kubernetes-adoption-challenges-with-koray-oksay_hu_a03b62e091d8b4f9.png) Podcast In this episode of Cloud Native Compass, host David Flanagan talks with Koray Oksay, a Kubernetes consultant, trainer at Kubermatic, CNCF Ambassador, and organizer of KCD Istanbul. From this episode, you’ll learn how to overcome the challenges of learning new technologies, how to find motivation, and how to use real-world projects to improve skills. Koray shares personal experiences - how he moved from struggling with Perl and Python to using them effectively in production. [Listen](https://cloudnativecompass.fm/16) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Kubermatic Unplugged: Can't-Miss Sessions at Cloud Native Rejekts & KubeCon + CloudNativeCon Europe in London! - **URL:** https://www.kubermatic.com/blog/kubermatic-unplugged-cant-miss-sessions-at-kubecon-cloudnativecon-europe-2025/ - **Date:** 2026-04-30 - **Description:** Join Kubermatic at Cloud Native Rejekts EU and KubeCon + CloudNativeCon Europe in London for an unmissable lineup of sessions! - **Categories:** Company, Best Practices - **Tags:** Announcements, Kubernetes - **Authors:** Sebastian Scheele Kubermatic is making a standout presence at **Cloud Native Rejekts EU 2025** and **KubeCon + CloudNativeCon Europe 2025 in London**, delivering a top-tier lineup of talks covering everything from Kubernetes security, platform engineering and multi-cluster management to governance and community contributions. Whether you're looking to sharpen your technical skills or gain insights into the broader Kubernetes ecosystem, there's something for you. Pop by booth S461 for a proper chinwag with our team and dive into the latest Kubermatic innovations! Beyond the sessions, join us for live demos, expert conversations, and fun games! ## Cloud Native Rejekts EU 2025 Cloud Native Rejekts EU 2025 is where the cream of the crop in cloud-native innovation will gather, ready to stir the pot of creativity and technology. Think of it as the perfect blend of a cup of tea and a technical masterclass – warm, insightful, and brewed to perfection. Whether you're a seasoned cloud wizard or a keen newcomer, this event will give you a front-row seat to the latest breakthroughs in Kubernetes, DevOps, and more. 🔹 [Kyverno Chronicles: A DevSecOps Tale — Koray Oksay, Kubernetes Consultant at Kubermatic](https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-europe-london-2025/talk/AVD8ZE/) 30 March, 15:10 GMT Securing Kubernetes workloads can be a complex challenge, especially when managing multiple clusters and enforcing compliance. In this talk, **Koray Oksay** will delve into how **Kyverno**, a Kubernetes-native policy engine, simplifies security and policy automation. Expect a deep dive into Kyverno's **architecture, features, and real-world use cases** to help you automate policy management and enforce policies at scale, making it easier to secure your Kubernetes workloads. 🔗 [Check the schedule](https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-europe-london-2025/talk/AVD8ZE/) 🔹 [Evaluating Global Load Balancing Options for Kubernetes in Practice — Tobias Schneck, Principal Architect at Kubermatic with Nicolai Ort (Datev)](https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-europe-london-2025/talk/UFZNVH/) 31 March, 10:05 AM GMT Load balancing is a critical aspect of modern cloud deployments, particularly in hybrid environments. This session explores **Multi-Cluster Meshes vs. DNS-based Global Load Balancing**, evaluating **Cilium** and **K8GB** for real-world multi-cloud scenarios. Expect a hands-on demo, insights into disaster recovery, and practical recommendations. 🔗 [Check the schedule](https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-europe-london-2025/talk/UFZNVH/) ## Maintainer Summit Europe 2025 Whether you're knee-deep in code or just love a good debate about community governance, this summit is the perfect opportunity to sharpen your tools, broaden your network, and help steer the ship of tomorrow's tech. Come for the chats and stay for the breakthroughs. 🔹 [Opening Remarks - Mario Fahlandt, Customer Delivery Architect at Kubermatic, Karena Angell (Red Hat), Natali Vlatko (Cisco)](https://maintainersummiteu2025.sched.com/event/1tgOq/keynote-opening-remarks-karena-angell-red-hat-mario-fahlandt-kubermatic-natali-vlatko-cisco) 31 March, 09:00 AM BST Start the summit with key insights from community leaders as they set the stage for an engaging event. 🔗 [Check the schedule](https://maintainersummiteu2025.sched.com/event/1tgOq/keynote-opening-remarks-karena-angell-red-hat-mario-fahlandt-kubermatic-natali-vlatko-cisco) 🔹 [Comms & Social Media – Why Does a Project Need It? — Mario Fahlandt, Customer Delivery Architect at Kubermatic with Chris Short (AWS)](https://maintainersummiteu2025.sched.com/event/1uSNh/comms-social-media-why-does-a-project-need-it-mario-fahlandt-kubermatic-chris-short-amazon-web-services) 31 March, 15:20 BST Every project has a website, and many have social media channels — but managing communications effectively is easier said than done. This talk explores how **open-source projects can establish clear communication strategies, social media policies, and crisis comms plans** to build a strong community. 🔗 [Check the schedule](https://maintainersummiteu2025.sched.com/event/1uSNh/comms-social-media-why-does-a-project-need-it-mario-fahlandt-kubermatic-chris-short-amazon-web-services) ## KubeCon + CloudNativeCon Europe 2025 Whether you're learning from industry leaders, discovering the latest tech trends, or networking, KubeCon + CloudNativeCon offers a front-row seat to the future of technology. So get your hands dirty in the latest tools, catch up on the trends, and have a pint or two of tech wisdom with like-minded innovators. 🔹 [Building a Cloud Native Curriculum for Real-World Readiness – Marko Mudrinić, Senior Software Engineer at Kubermatic](https://colocatedeventseu2025.sched.com/event/1u5gm) 1 April, 15:55 BST, at Cloud Native University As Cloud Native technology becomes the industry standard, how do we ensure students are job-ready? Marko shares insights from designing a **DevOps and Kubernetes-focused curriculum**, tackling challenges like **large-scale projects, CI/CD, and open-source contributions** — all within a tight 13-week timeframe. 🔗 [Check the schedule](https://colocatedeventseu2025.sched.com/event/1u5gm) 🔹 [Tutorial: Exploring Multi-Tenant Kubernetes APIs and Controllers with Kcp — Senior Software Engineer at Kubermatic, Robert Vasek (Clyso), Nabarun Pal (Broadcom), Varsha Narsing (Red Hat), Mangirdas Judeikis (Cast AI)](https://kccnceu2025.sched.com/event/1tx6b) 2 April, 11:15 BST Multi-tenancy in Kubernetes is a complex challenge, but **Kcp** introduces a fresh approach to managing workloads across multiple tenants. In this **hands-on tutorial**, learn how to **extend Kubernetes, build APIs, and design controllers** to create **scalable, multi-tenant platforms**. 🔗 [Check the schedule](https://kccnceu2025.sched.com/event/1tx6b) 🔹 [Dynamic Multi-Cluster Controllers with Controller-runtime — Marvin Beckers (Kubermatic) with Stefan Schimanski (Upbound)](https://kccnceu2025.sched.com/event/1txFM) 3 April, 15:00 BST The Kubernetes landscape is rapidly evolving, and multi-cluster management is now the norm. This talk explores how to **build controllers that reconcile resources across dynamic Kubernetes clusters**, with practical guidance on implementing **dynamic cluster providers, event handlers, and reconcilers**. 🔗 [Check the schedule](https://kccnceu2025.sched.com/event/1txFM) 🔹 [Navigating the Inevitable: Kubernetes Breaking Changes Behind the Scenes – Marko Mudrinić, Senior Software Engineer at Kubermatic](https://kccnceu2025.sched.com/event/1txH3) 3 April, 16:00 BST Ever been excited about a new Kubernetes feature, only for it to be removed or deprecated? This session reveals **why breaking changes happen**, how maintainers make these tough decisions, and what you can do to **stay informed and contribute to the process**. 🔗 [Check the schedule](https://kccnceu2025.sched.com/event/1txH3) 🔹 [Contributing to Kubernetes in Its Second Decade – How ContribEx Enhances the Journey! — Mario Fahlandt (Kubermatic), Nabarun Pal (Broadcom), Madhav Jivrajan (UIUC), Priyanka Saggu (SUSE)](https://kccnceu2025.sched.com/event/1td1K) 4 April, 11:45 BST The **Kubernetes Contributor Experience SIG** has been pivotal in growing the community, but sustaining contributors is just as important as recruiting them. This session covers **Kubernetes governance, where to find help, common pitfalls, and how you can get involved —** whether in **marketing, automation, event planning, or content creation**. 🔗 [Check the schedule](https://kccnceu2025.sched.com/event/1td1K) ## London is calling, and we can't wait to meet you there! Whether you're keen to enhance your Kubernetes security, master multi-cluster controllers, or contribute to the ecosystem, Kubermatic's sessions will provide invaluable insights, hands-on expertise, and practical takeaways — all served with a touch of British charm. Mark your calendars, grab a brew, and join us at **booth S461** — it's bound to be a smashing good time! --- ## KKP 2.27: Introducing AI Kit and more - **URL:** https://www.kubermatic.com/blog/kkp-2-27-ai-kit-enhanced-backup-feature-and-more-exciting-advancements/ - **Date:** 2026-04-30 - **Description:** Check out the latest features introduced in KKP 2.27, including AI Kit, enhanced backup feature and more. - **Categories:** Products - **Tags:** KKP - **Authors:** Csenger Szabo We're thrilled to announce the release of the [Kubermatic Kubernetes Platform](/products/kubermatic-kubernetes-platform/) (KKP) 2.27! This version introduces several exciting features and improvements to elevate your journey with Kubernetes. With Cluster Backup across KKP instances for disaster recovery, AI Kit and support for Kubernetes 1.32, KKP 2.27 ensures you're up-to-date with the latest advancements. Let's explore the best improvements of this version. ## Highlighted Features ### Cluster Backup: Restore to Another KKP Cluster Disaster recovery and migration just got easier! With KKP 2.27, users can restore cluster backups to a completely different KKP instance. This enhancement enables greater flexibility in handling failures, transitions between environments, or even planned migrations. By decoupling the backup-restore process from a single KKP instance, users gain an additional layer of resilience and operational agility. ### Admin Announcement Feature: Seamless Communication Across the Platform Keeping all users informed is crucial in any Kubernetes environment, and with the **new admin announcement feature**, KKP administrators can now broadcast important messages directly within the platform. Whether it's planned maintenance, policy updates, or alerts, this feature ensures that all users are aware of critical information without relying on external communication channels. ### AI Kit in KKP: Deploying AI, GenAI, and LLM Workloads at Scale KKP now includes AI Kit as an application in the App Catalog, enabling seamless deployment of AI, Generative AI (GenAI), and Large Language Model (LLM) workloads in Kubernetes environments. AI Kit simplifies running inference and fine-tuning LLMs and machine learning models with optimized performance for both CPU and GPU-based workloads. With support for multi-modal models, air-gapped environments, OpenAI API compatibility, and Kubernetes-ready configurations, AI Kit allows enterprises to efficiently deploy LLM-based AI applications, chatbots, and fine-tuning workflows in production. Leveraging KKP's multi-cloud automation and GPU acceleration, users can easily integrate edge AI inference, scalable AI APIs, and secure, high-performance model serving across their clusters. KKP provides a reliable, scalable platform for AI-driven innovation in cloud-native and edge AI environments. ### Cluster Autoscaler as an Application: More Flexibility in Scaling KKP 2.27 shifts the **cluster-autoscaler** from being an add-on to an application, giving users better flexibility and control over its deployment and lifecycle. By treating the autoscaler as an app, KKP allows for easier updates, customization, and integration with existing application management workflows. This change ensures that clusters can dynamically adjust to workload demands in a more streamlined manner. ### Kubernetes 1.32 Support: Keeping Up with the Latest Advancements Kubermatic Kubernetes Platform (KKP) now fully supports Kubernetes 1.32, ensuring compatibility with the latest upstream improvements, security patches, and performance optimizations. This update provides users with cutting-edge enhancements in scalability and reliability while maintaining seamless operations across cloud and on-prem environments. With this upgrade, KKP continues to offer enterprise-grade Kubernetes management with minimal friction when adopting new versions. ## Other Valuable Features ### KubeVirt Improvements: Better Virtualization Experience KKP 2.27 introduces a series of **KubeVirt improvements**, further solidifying its support for running virtual machines alongside containers. These enhancements include better UI integration, performance optimizations, and refined network handling, making KubeVirt a more reliable solution for hybrid workloads within Kubernetes clusters. ### RHEL 9 Support: Expanding Compatibility KKP 2.27 adds **support for Red Hat Enterprise Linux 9 (RHEL 9)**, enabling users to deploy clusters on the latest enterprise-grade Linux distribution. This ensures compatibility with modern workloads and security standards while allowing organizations to take advantage of RHEL's stability and support. Furthermore, in alignment with the industry-wide shift, **CentOS support has been removed** from KKP. ### Applications improvements #### Default Namespace for Applications To enhance consistency and streamline application deployment, KKP now supports **default namespaces for applications**. This improvement allows users to define a standard namespace when installing applications, reducing the risk of misconfigurations and improving overall cluster hygiene. To learn more about namespaces, visit [our previous blog](/blog/kubernetes-namespaces/). #### Pre-Defined KKP Variables in Applications Users can now leverage **pre-defined KKP variables** within applications, simplifying configuration management and ensuring dynamic values are applied without manual intervention. This enhancement reduces human error and makes it easier to standardize application deployments across multiple clusters. #### Application Versions Refreshed In KKP 2.27, the default App Catalog has been refreshed with the latest versions of its applications. This update ensures that users have access to the most recent features and security patches when deploying applications from the catalog. While this enhancement improves the baseline for new deployments, users are encouraged to review and manage application versions to maintain optimal performance and security within their clusters. #### ArgoCD-Based KKP Apps Helm Chart (Alpha) KKP 2.27 introduces an **initial ArgoCD-based Helm chart** for managing KKP applications, providing a GitOps-friendly approach to application lifecycle management. This allows users to leverage ArgoCD's declarative model to maintain consistency and control across their Kubernetes applications. ### Platform Administration Improvements #### Display Only Admin-Allowed OS in Project Add/Edit Dialog For enhanced control, KKP now ensures that **only administrator-approved operating systems** are displayed when adding or editing projects. This prevents unauthorized OS choices and enforces compliance with internal policies. #### Seed CR: Default Image ID Specification KKP now allows users to **optionally specify a default image ID in the Seed Custom Resource (CR)**, providing greater control over how nodes are provisioned within clusters. This feature simplifies cluster setup and ensures consistent image usage across deployments. #### Secure UserCluster NodePorts by Default To bolster security, KKP gives the option to override the default setting (0.0.0.0/0), by setting NodePortsAllowedIPRanges on the OpenStack datacenter level. This change minimizes potential attack vectors by enforcing strict access controls while maintaining flexibility for administrators to fine-tune access policies as needed. ### Technical improvements #### New Dex Helm Chart for OAuth Authentication A **new Dex Helm chart** replaces the previous OAuth chart, improving authentication and identity management capabilities in KKP. This change ensures a more streamlined and secure authentication process for users integrating with external identity providers. #### API Server Service Type Configuration KKP now allows users to **configure the API server service type**, offering greater control over networking and accessibility. This feature provides more flexibility when deploying clusters in different environments, improving the overall deployment experience. We're excited to see how these features will empower your Kubernetes operations and look forward to accompanying you on your cloud-native journey. Stay tuned for future updates and don't hesitate to reach out with any questions or suggestions via [Contact Us](/contact-us/) form. --- ## Multi-Cluster Kubernetes Management With Operators - **URL:** https://www.kubermatic.com/blog/how-to-manage-multi-cluster-kubernetes-with-operators/ - **Date:** 2026-04-30 - **Description:** Kubermatic Kubernetes Platform runs Kubernetes in Kubernetes to automate deployment, operations, and life cycle management across clusters and clouds - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Sascha Haase At Kubermatic, we have been helping our customers deliver Kubernetes clusters and other cloud native solutions since before they were buzzwords. We helped customers build clusters using Ansible, Terraform, and a variety of other non cloud native tools...and we helped them rebuild the clusters when we ran into the limits of these tools. In these early days, two things quickly became clear to us: 1) Kubernetes is not a single large cluster solution, but rather requires a larger number of smaller clusters 2) Kubernetes multi-cluster management needs cloud native tools built for a declarative, API driven world. Since then, these ideas have largely been validated by a variety of organizations around the world including the CNCF, [Adidas](https://kubernetes.io/case-studies/adidas/), [Twitter](https://www.alibabacloud.com/blog/what-can-we-learn-from-twitters-move-to-kubernetes_595156), [USA Today](https://medium.com/usa-today-network/there-and-back-again-scaling-multi-tenant-kubernetes-cluster-s-67afb437716c), [Zalando](https://www.youtube.com/watch?v=LpFApeaGv7A), and [Alibaba](https://www.cncf.io/blog/2019/12/12/demystifying-kubernetes-as-a-service-how-does-alibaba-cloud-manage-10000s-of-kubernetes-clusters/). Knowing that every company running Kubernetes at scale would need to effectively administer multi-cluster management, we created the open source Kubermatic Kubernetes Platform. This blog post will cover why you need multi-cluster management, how Kubermatic Kubernetes Platform leverages Kubernetes Operators to automate cluster life cycle management across multiple clusters, clouds, and regions and how you can get started with it today. ## Why You Need Multi-Cluster Management Kubernetes lacks hard multi-tenancy capabilities that give users, organizations, or operators the ability to allow untrusted tenants to share infrastructure resources or separate different pieces of software. This presents both a security and operational problem. When operators seek to separate workloads by type (sensitive vs nonsensitive data processing) or even just production vs non-production there is no way to do this on the cluster level; creating a security nightmare. On the operational side, trying to deploy too many applications into the same cluster can result in version conflicts, configuration conflicts, and problems with software lifecycle management. Finally, without proper isolation there is an increased risk of cascading failures.  Without hard multi-tenancy within a cluster, separate clusters must be used to provide adequate separation for workloads with different security requirements. Having multiple clusters to deploy applications into also allows operators to deploy similar applications together while segregating those with different life cycles from each other. Applications deployed into the same cluster can be upgraded together to reduce the operational load while applications that require different versions, configurations, and dependencies can run in separate clusters and be upgraded on their own.  If running multiple clusters is the only solution to meeting these workload and infrastructure requirements, the operational burden of this model must also be considered. Running a multitude of clusters is a massive operational challenge if done manually. For this reason, any operator considering running Kubernetes at scale should carefully evaluate their multi-cluster management strategy. At Kubermatic, we have chosen to do multi-cluster management with Kubernetes Operators.  ## What Is a Kubernetes Operator? An Operator is a piece of software that understands how to run and facilitates operating another piece of software. More technically, as CoreOS, who introduced the first Kubernetes Operator in 2016, notes: An Operator is a method of packaging, deploying and managing a Kubernetes application. A Kubernetes application is an application that is both deployed on Kubernetes and managed using the Kubernetes APIs and kubectl tooling. An Operator has its custom controller watching the custom resources specifically defined for the applications. This allows developers to codify life cycle management knowledge for applications that need to maintain state and thereby automates much of the ongoing management including deployments, backups, upgrades, logging, and alerting by simply watching events and leveraging the reconciliation loops built into Kubernetes. In short. a well built operator covers the complete lifecycle of a containerized software. ## How Do We Use Kubernetes Operators to Do Multi-Cluster Management? With Kubermatic Kubernetes Platform, we extend the Operators paradigm beyond applications to manage the clusters themselves. Yes, we are using Kubernetes to operate Kubernetes. This model has actually been proven out by multiple organizations including [Alibaba](https://www.cncf.io/blog/2019/12/12/demystifying-kubernetes-as-a-service-how-does-alibaba-cloud-manage-10000s-of-kubernetes-clusters/) who uses it to manage tens of thousands of clusters. On a technical level, the cluster state is defined in Custom Resource Definitions then stored within etcd. A set of controllers and their associated reconciliation loops watch for changes or additions to the cluster state and update each as required. All state is stored in a “Seed Cluster”. When a new user cluster is defined, the control plane (API, etcd, Scheduler, and Controllers) is created as a Deployment of containers within a namespace of the seed cluster. The worker nodes of the user cluster are deployed by [machine-controller](https://github.com/kubermatic/machine-controller) which implements [Cluster API](https://github.com/kubernetes-sigs/cluster-api) to bring declarative creation, configuration, and management to worker nodes. Operators allow Kubermatic Kubernetes Platform to automate not only the creation of clusters, but also their full life cycle management. Updating the control plane is merely doing a rolling update of a deployment of containers while updating the actual nodes in the cluster can also be done declaratively in a roll fashion. ![Cluster Architecture](/static/how-to-do-kubernetes-multi-cluster-management-with-operators_cluster-architecture.png) Leveraging Kubernetes Operators also gives a consistent abstraction across all infrastructure providers, whether at the edge, on-prem, or in the cloud. Rather than reinventing the wheel for each one, the same tooling can easily be ported from one provider to the next including hybrid and multi-cloud as well as integrating on-premise infrastructure (virtualized and bare metal). ![Multi-Cluster Architecture](/static/how-to-do-kubernetes-multi-cluster-management-with-operators_multi-cluster-architecture.png) ## What Do Operators Allow Our Users to Do? While creating an elegant solution to a difficult technical problem has been an exciting journey and learning experience, the most gratifying part has been seeing the impact it has on our users every day. As partners on their cloud native journey, we love to see the results of our software speak for themselves. SysEleven, a managed hosting provider out of Berlin, was our first production user. They wanted to be able to provide Kubernetes-as-a-Service to their customers, but knew they couldn’t scale the operations through people. They chose Kubermatic Kubernetes Platform to scale through software instead and have had it in production for almost 3 years. Because the Kubernetes Operators behind Kubermatic Kubernetes Platform automate many of their operational tasks including the classic “turn it off and turn it back on again”, they are able to run and manage hundreds of clusters with just one FTE. This has allowed their Kubernetes team to focus on customer demands and deliver the high quality service they have become known for. You can read about their whole journey with us [here](/customers/syseleven/). Above and beyond the cloud-native journey, operators also allow us to adopt our proven principles and processes to adapt to the edge. ## How to Get Started In 2020, we open-sourced Kubermatic Kubernetes Platform to help as many companies as possible accelerate their cloud native journey. You can find the code on [Github](https://github.com/kubermatic/kubermatic), the [documentation](https://docs.kubermatic.com/kubermatic/latest) on our website, and our community on {{< slackjoinlink "Slack" >}}. We are excited to see you automate your multi cluster management with Kubernetes Operators! --- ## Cloud Native Multi-Tenant Load Balancing - **URL:** https://www.kubermatic.com/resources/cloud-native-multi-tenant-load-balancing/ - **Date:** 2026-05-07 - **Description:** Discover how application architectures have evolved and how KubeLB's distributed microservices can dramatically reduce the operational impact of microservices-based application architectures. # Cloud Native Multi-Tenant Load Balancing ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Whitepaper Discover how application architectures have evolved and how KubeLB’s distributed microservices can dramatically reduce the operational impact of microservices-based application architectures. [Download](/whitepaper-kubelb-cloud-native-multi-tenant-load-balancer/) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## The Value of Internal Developer Platforms - **URL:** https://www.kubermatic.com/resources/the-value-of-internal-developer-platforms/ - **Date:** 2025-11-05 - **Description:** Explore all the benefits of Internal Developer Platforms, including centralized service management, automation, flexibility, scalability, and more. # The Value of Internal Developer Platforms ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Whitepaper Explore all the benefits of Internal Developer Platforms, including centralized service management, automation, flexibility, scalability, and more. [Read](/whitepaper-kdp-empower-developers-accelerate-innovation/) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Empower Developers and Accelerate Innovation with Kubermatic Developer Platform - **URL:** https://www.kubermatic.com/resources/empower-developers-and-accelerate-innovation-with-kubermatic-developer-platform/ - **Date:** 2025-11-05 - **Description:** Explore how to maximize developers' productivity and accelerate innovation using KDP. Powered by Kubernetes API and based on CNCF Sandbox Project kcp, KDP allows service management through a centralized catalog and other features explored in this solution brief. # Empower Developers and Accelerate Innovation with Kubermatic Developer Platform ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Solution Briefs Explore how to maximize developers’ productivity and accelerate innovation using KDP. Powered by Kubernetes API and based on CNCF Sandbox Project kcp, KDP allows service management through a centralized catalog and other features explored in this solution brief. [Download](/solution-brief-empower-developers-and-accelerate-innovation-with-kubermatic-developer-platform/) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## kcp - kube-like control plane - **URL:** https://www.kubermatic.com/kcp/ - **Date:** 2026-03-30 - **Description:** Learn all about kcp, what it is, how the project started, and find all the resources to help you understand it. # kcp An open source horizontally scalable control plane for Kubernetes-like APIs. A CNCF Sandbox Project. ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## An Introduction to kcp The [CNCF Sandbox](https://www.cncf.io/sandbox-projects/) [project kcp](https://www.kcp.io/) is pioneering the development of a Kubernetes-like control plane to provide arbitrary services through a unified platform and resource model. kcp is dedicated to building a robust, scalable foundation for control planes that transcend container orchestration, while maintaining 100% compatibility with: - Kubernetes API Machinery - Non-domain-specific Kubernetes APIs - The Kubernetes ecosystem of libraries and tooling. kcp expands the reach of cloud-native tech by offering flexibility beyond the traditional Kubernetes control plane. Users can easily adapt kcp to diverse infrastructures without overhauling existing systems. ![kcp logo](/static/kcp-logo.svg) - ![consistency icon](/static/icons/consistency-icon.svg) ### Simplified Integration - ![graph chart icon](/images/icons/graph-chart.svg) ### Enhanced scalability - ![exchange icon](/static/exchange-icon.svg) ### Unified API Platform - ![magnify user icon](/images/icons/magnify-user-icon.svg) ### Improved Flexibility and Isolation ## kcp's Important Milestones - ### 2020 kcp launches as a research project - ### 2022 Launch of project website - ### 2023 **May** Community governance takes over **September** kcp joins CNCF Sandbox - ### 2025 API stabilization ## Community [kcp](https://www.kcp.io/) thrives on the contributions and support of its community. At Kubermatic, we're proud to support this community as the one of the [main enterprise contributors](https://kcp.devstats.cncf.io/d/5/companies-table?orgId=1&var-period_name=Last%20year&var-metric=contributions). ### Meet our contributors We take great pride in our dedicated team members who are actively involved in the kcp project as both maintainers and developers. [Sebastian Scheele](https://www.linkedin.com/in/sebastian-scheele/), Kubermatic's Co-Founder and CEO, became one of the three initial maintainers after the governance transfer. [Christoph Mewes](https://github.com/xrstf), [Simon Bein](http://github.com/SimonTheLeg), [Marko Mudrinić](http://github.com/xmudrii), and [Marvin Beckers](https://marvin.beckers.dev/) contribute significantly to the kcp project. If you are interested in joining the growing kcp community, join kcp in the #kcp-dev Slack channel on the [Kubernetes Slack](https://kubernetes.slack.com/) or on the [bi-weekly community calls on Thursdays](https://groups.google.com/g/kcp-users?pli=1). Visit the oficial [kcp project page](https://www.kcp.io/) and [GitHub](https://github.com/kcp-dev/kcp) for more information. [Join the community calls](https://groups.google.com/g/kcp-users?pli=1) ![Sebastian Scheele](/static/Sebastian-Scheele.jpg) ![Marvin Beckers](/static/Marvin-Beckers-squared.jpg) ![Christoph Mewes](/static/christoph-mewes-2.jpg) ![Marko Mudrinić](/static/marko-mudrinic-2.jpg) ![Simon Bein](/static/authors/simon-bein.jpeg) ## What to build with kcp ### SaaS / PaaS / IaaS A order API/interface for your cloud service. ### Global Control Plane An orchestration layer for global infrastructure. ### Platform mesh Connect and compose multiple internal platforms into a unified control plane. [Explore it](https://platform-mesh.io/) ### Kubernetes-API-aaS Managed Kubernetes-like API endpoints (logical clusters) to be used for other use cases. ### Internal Developer Platform Allowing internal developers to manage their various resources needed for development and running apps. Kubermatic Developer Platform is built on top of kcp [Explore KDP](/products/kubermatic-developer-platform/) At Kubermatic, we're using kcp to build KDP - the Intermal Developer Platform to maximize developer productivity and accelerate innovation. **Powered by Kubernetes API, based on kcp, KDP enables the creation and management of services backed by a centralized service catalog**. [Explore KDP](/products/kubermatic-developer-platform/) ![kcp logo](/static/kdp-illustration-2.svg) ## Resource section **To learn more about kcp, watch one of the talks from Marvin & Sebastian Scheeles, or listen to the podcast.** [![](/static/building-a-platform-engineering-api-layer-with-kcp_hu_b6868c49a90bd9cb.jpg)](/resources/building-a-platform-engineering-api-layer-with-kcp/) Video ## [Building a Platform Engineering API Layer with kcp - Platform Engineering Day](/resources/building-a-platform-engineering-api-layer-with-kcp/) This talk discusses how kcp supercharges platform engineering with a global control plane for all internal services. [View](/resources/building-a-platform-engineering-api-layer-with-kcp/) [![](/static/cds-2024-building-a-platform-engineering-api-layer-with-kcp_hu_7ffa7ac9dae5e559.jpg)](/resources/building-a-platform-engineering-api-layer-with-kcp-cds24/) Video ## [Building a Platform Engineering API Layer with kcp - CDS 2024](/resources/building-a-platform-engineering-api-layer-with-kcp-cds24/) kcp expands the world of platform engineering beyond the limits of single Kubernetes clusters, and therefore transforms the scale at which platform teams and internal service providers can operate. [View](/resources/building-a-platform-engineering-api-layer-with-kcp-cds24/) [![](/static/kubernetes-style-apis-for-saas-like-control-planes-with-kcp_hu_7b17238e412441d.jpg)](/resources/kubernetes-style-apis-for-saas-like-control-planes-with-kcp/) Video ## [Kubernetes-style APIS for SaaS-like Control Planes with kcp](/resources/kubernetes-style-apis-for-saas-like-control-planes-with-kcp/) Explore the core concepts that kcp adds to the Kubernetes API and discover how kcp could be the right fit for your next platform based on cloud native technologies. [View](/resources/kubernetes-style-apis-for-saas-like-control-planes-with-kcp/) [![](/static/why-kubernetes-is-inappropriate-for-platforms-and-how-to-make-it-better_hu_5c4b5d80ca5f3f9c.jpg)](/resources/why-kubernetes-is-inappropriate-for-platforms-and-how-to-make-it-better/) Video ## [Why Kubernetes is Inappropriate for Platforms and How to Make it Better](/resources/why-kubernetes-is-inappropriate-for-platforms-and-how-to-make-it-better/) This talk is about extending Kube, adapting its architecture to be a better fit for a world where instead of container orchestration two new personas are at the center. [View](/resources/why-kubernetes-is-inappropriate-for-platforms-and-how-to-make-it-better/) [![](/static/kubernetes-podcast-image-of-marvin-beckers_hu_b19609c6ac24f09e.png)](/resources/kubernetes-podcast-kcp-the-future-of-kubernetes-and-multi-tenancy/) Podcast ## [Kubernetes Podcast: KCP - The Future of Kubernetes and Multi-Tenancy](/resources/kubernetes-podcast-kcp-the-future-of-kubernetes-and-multi-tenancy/) During this episode, you will hear all about multi-tenant solutions, cluster management utilities, and the advantages of KCP over traditional Kubernetes setups. [Listen](/resources/kubernetes-podcast-kcp-the-future-of-kubernetes-and-multi-tenancy/) --- ## Gazing Into the Cloud Native Crystal Ball: 2025 Predictions Shaping the Future of Container Management - **URL:** https://www.kubermatic.com/blog/gazing-into-the-cloud-native-crystal-ball-2025-predictions-shaping-the-future-of-container-management/ - **Date:** 2026-04-30 - **Description:** Discover the future of cloud-native computing with 2025's top predictions! From serverless containers and AI/ML integration to edge computing and Internal Developer Platforms (IDPs). - **Categories:** Company - **Tags:** Announcements - **Authors:** Sebastian Scheele The cloud-native landscape has transformed businesses and technology over the past decade, and as we venture into 2025, it's clear that its evolution is far from over. With containers, microservices, and Kubernetes at the forefront, the ecosystem continues to redefine how organizations build, deploy, and manage applications. But as complexity grows, will 2025 be the year that **Internal Developer Platforms (IDPs)** become the cornerstone of simplifying cloud-native operations? Alongside this question, we anticipate key trends shaping cloud-native computing's future, with [Gartner® predictions](https://www.linkedin.com/posts/kubermatic_kubernetes-devops-k8s-activity-7282304961302913024-nGqf) highlighting that *"Container management is meeting or exceeding enterprise needs and expanding beyond the public cloud to other computing environments, including serverless offerings, while supporting emerging AI use cases."*\* ## The Rise of Serverless Containers Serverless computing has been a buzzword for years, but 2025 marks a turning point for its synergy with containers. Serverless containers bridge the gap between the efficiency of containerized workloads and the simplicity of serverless computing. These solutions offer on-demand scalability without the need to manage underlying infrastructure, enabling businesses to focus on innovation rather than operational overhead. According to **Gartner Predicts 2025: Container Management Goes Mainstream Report** *"By 2027, more than half of all container management deployments will involve serverless container management services, which is a significant increase from fewer than 25% in 2024"*. <img src="/static/gartner-three-predictions-impacting-the-evolution-of-container-management.png" alt="Gartner three predictions impacting the evolution of container management" width="786" height="320" loading="lazy"> As developers continue to demand flexibility and cost efficiency, serverless containers will become the go-to model for running cloud-native applications. This evolution will help organizations optimize resource allocation, streamline workflows, and achieve greater agility in responding to market changes. ## AI and ML Meet Cloud Native Artificial intelligence (AI) and machine learning (ML) are reshaping industries, and in 2025, their impact on cloud-native ecosystems will be profound. AI/ML workloads require scalable, resource-intensive infrastructure, making containers and Kubernetes an ideal pairing for these technologies. The rise of containerized AI/ML applications is fueled by: - **Rapid Deployment**: Containers provide a consistent environment to train, test, and deploy models. - **Scalable Infrastructure**: Kubernetes ensures workloads can scale dynamically to meet demand. - **Specialized Tools**: Technologies like Kubeflow simplify the orchestration of complex AI/ML workflows. Organizations will increasingly adopt Kubernetes-based platforms to handle AI/ML workloads, from predictive analytics to real-time decision-making. This trend underscores the growing role of cloud-native solutions in powering next-gen innovations. ## Platform Engineering: Simplifying the Complex with Internal Developer Platforms Amid these transformative trends, platform engineering is becoming the glue that holds modern cloud-native strategies together. Kubernetes and the broader cloud-native ecosystem have unlocked unparalleled capabilities—but they've also introduced significant complexity. [Enter Internal Developer Platforms (IDPs)](/topics/internal-developer-platforms/): standardized, user-friendly platforms designed to abstract operational overhead and empower developers. One such game-changing platform is the [**Kubermatic Developer Platform (KDP)**](/products/kubermatic-developer-platform/), engineered to revolutionize how internal development teams operate. KDP streamlines software deployment and service management through a centralized service catalog, making internal platforms smarter, lighter, and more efficient. Built on [**kcp**](https://www.kcp.io/), a Cloud Native Computing Foundation ([CNCF](https://www.cncf.io/)) Sandbox project, where [**Kubermatic**](/) is a main contributor, KDP simplifies Kubernetes management, enabling your team to focus on what truly matters—delivering value, not managing infrastructure complexities. By integrating best practices, security measures, and observability tools into a curated, self-service experience, IDPs enable teams to focus on delivering value without being bogged down by the intricacies of Kubernetes. This approach doesn't just simplify workflows; it provides a foundation for secure, scalable, and efficient development pipelines. Platform engineering ensures that organizations can adopt and scale cloud-native technologies effectively while maintaining control and reducing operational friction. ## Multi-Cloud and Hybrid Environments Take Center Stage The future is undeniably multi-cloud. Organizations are moving beyond single-provider strategies to embrace hybrid and multi-cloud environments, leveraging the best of each platform. Kubernetes will play a pivotal role in enabling this transition, providing a unified orchestration layer across public, private, and edge infrastructures. In 2025, we'll see: - **Advanced Management Solutions**: Control panels and tools designed for seamless multi-environment operations. - **Vendor-Agnostic Platforms**: Solutions that eliminate vendor lock-in while ensuring interoperability. - **Optimized Workloads**: AI-driven analytics to determine the ideal environment for every workload. Businesses will prioritize flexibility and scalability, leveraging multi-cloud setups to achieve resilience and cost efficiency. ## Democratizing Cloud-Native Expertise Despite its transformative potential, container-related expertise remains a bottleneck for many organizations. In 2025, we anticipate a shift toward democratizing cloud-native knowledge through: - **Platform Engineering Teams**: Centralized groups responsible for infrastructure platform development and support. - **Enhanced Marketplaces**: Vendor ecosystems offering third-party container tools and Kubernetes Operators to simplify lifecycle management. - **Education and Certification**: Expanded training programs to bridge the skill gap and empower IT teams. As cloud-native technologies become more accessible, organizations will unlock greater value from their investments, accelerating innovation and growth. ## Edge Computing: Cloud Native Goes Decentralized [Edge computing](/topics/edge-computing/) is no longer a niche solution. By 2025, it will be a cornerstone of cloud-native strategy, enabling organizations to deploy and manage applications closer to where data is generated. This shift is crucial for industries like retail, manufacturing, and telecommunications, where latency, bandwidth, and real-time processing are critical. Key developments driving edge computing include: - **Containers at the Edge**: Lightweight containerized workloads offer efficient operation across diverse edge devices. - **Kubernetes on the Edge**: Unified control planes allow seamless management of edge and cloud environments. - **Data Localization**: Enhanced compliance and security for industries with strict data sovereignty requirements. The convergence of edge computing and cloud-native technologies will redefine how businesses operate in remote and distributed environments, delivering unparalleled agility and performance. ## What This Means for Enterprises in 2025 The predictions for 2025 reflect a cloud-native ecosystem that is more powerful, flexible, and integrated than ever. From serverless containers to edge computing and AI-driven workloads, the trends shaping this year underscore the need for businesses to adapt and evolve. For enterprises, this means: - **Embracing New Models**: Transitioning to serverless containers and edge strategies to stay competitive. - **Investing in AI/ML**: Leveraging containerized infrastructure to power data-driven decision-making. - **Adopting Multi-Cloud Architectures**: Prioritizing flexibility and resilience in workload deployment. - **Upskilling Teams**: Building internal expertise to fully capitalize on cloud-native capabilities. Organizations that proactively adapt to these trends will not only thrive in 2025 but also set the stage for sustained success in an increasingly digital world. ## Final Thoughts The trends and solutions shaping 2025 reflect the growing maturity of the cloud-native ecosystem. From serverless containers and AI/ML integration to edge computing and the rise of IDPs, organizations have more tools than ever to drive innovation and efficiency. However, success will require a clear strategy, investment in the right technologies, and a focus on simplifying complexity through platform engineering. As we gaze into the cloud-native crystal ball, one thing is clear: 2025 will be a year of transformation, collaboration, and growth, setting the stage for even greater advancements in the years ahead. Ready to explore these trends and reshape your cloud-native strategy? Now is the time to act. <br/> --- <small> <em> *Gartner, Predicts 2025: Container Management Goes Mainstream, By Dennis Smith, 5 December 2024.<br> GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved. </em> </small> <br/><br/><br/><br/> --- ## Main reasons why businesses are moving away from public clouds - **URL:** https://www.kubermatic.com/blog/main-reasons-why-businesses-are-moving-away-from-public-clouds/ - **Date:** 2026-04-30 - **Description:** Over the past few years, businesses have been migrating away from the public cloud. This blog explores the key reasons behind public cloud repatriation and what it means for your organization. - **Categories:** Community, Best Practices - **Tags:** Open Source Projects, Kubernetes - **Authors:** Sebastian Scheele Recently, a statistic has been sparking debates about the choice between public and private cloud infrastructures. According to the 2024 CIO survey by Barkley, a surprising 83% of enterprises plan to move their workloads back to private clouds. Michael Dell, CEO of Dell Technologies, remarked that these findings were "not surprising." Similarly, the cloud analysis firm IDC has observed a similar trend, reporting that 70% of enterprises are shifting their workloads back to on-premises or hybrid cloud environments. This raises the question: what is driving this migration back to private clouds? ## The Advantages and Disadvantages of Public Clouds Public clouds, operated by third-party service providers, have become especially popular among startups and small to mid-sized companies. The main reason for this trend is that public clouds reduce entry barriers and initial costs. Businesses using the public cloud avoid the need to invest in physical hardware and an in-house IT team to manage it. Instead, the public cloud infrastructure is shared among many companies, providing the best economies of scale, and eliminating the need for a large upfront investment. Additionally, public cloud infrastructures offer quick, on-demand scalability. Due to its pay-per-use model, the public cloud can quickly adjust to varying workloads without requiring companies to commit to physical resources. However, the public cloud model doesn't come without its downsides. While public clouds have robust security measures in place, their shared infrastructure can become a point of concern for industries handling sensitive data, such as financial institutions. The shared nature of public clouds inherently increases the risk of unauthorized access or data breaches, making them a less attractive option for companies managing confidential data. Additionally, public clouds offer limited control for businesses looking to establish specific configurations and data management protocols. In a shared cloud environment, companies must adhere to standardized configuration protocols set by the service provider, which can significantly limit customization. For industries and companies that require a tailored infrastructure, this lack of control can hinder their ability to optimize configurations for unique workflows or to meet regulatory requirements. <img src="/static/Pros-and-cons.png" alt="scale with pros and cons" width="786" height="300" loading="lazy"> ## The Repatriation Trend: Why Public Clouds Are Being "Kicked to the Curb" ### What is Repatriation? Repatriation refers to the process of moving applications, services, and data from public clouds to on-premises or private cloud infrastructure. This trend is part of a broader industry shift away from public clouds toward hybrid multi-cloud IT strategies. ### Reasons for the Cloud Repatriation Initially, many applications were moved to the cloud to take advantage of its flexibility and rapid deployment capabilities. However, over time, it has become clear that public clouds don't always provide cost savings at scale. As businesses mature and their need for rapid scalability decreases, public clouds no longer offer the same cost benefits. The commoditization of hardware over the past years, coupled with price declines, has made private clouds a more cost-efficient solution for running workloads. In fact, [37signals has left the public cloud](https://world.hey.com/dhh/we-have-left-the-cloud-251760fb), opting to build their own infrastructure. [David Heinemeier Hansson](https://www.linkedin.com/in/david-heinemeier-hansson-374b18221/) estimates annual savings of $1.5 million, signaling that the public cloud may not be the cost-efficient solution for medium to large enterprises. Additionally, according to the [IDC Cloud Pulse 4Q 2023 survey](https://blogs.idc.com/2024/10/28/storm-clouds-ahead-missed-expectations-in-cloud-computing/), close to half of cloud buyers experienced unexpected cost overruns, with 59% anticipating similar overruns in 2024. Another widespread concern with public clouds is vendor lock-in, as businesses risk becoming overly dependent on a specific provider. Since migrating data and applications to another platform can be complex, companies may become vulnerable to sudden price increases from their public cloud provider. This vulnerability is exemplified by Broadcom's recent [acquisition of VMware](/blog/vmware-the-death-of-an-industry-standard/) has resulted in a shift to a subscription-based licensing model. This change has led to significant cost increases for organizations, with some of them experiencing 2x to 5x increases in VMware renewal fees. Another factor driving businesses away from the public cloud is the advent of Artificial Intelligence (AI). While public clouds can handle AI workloads, the high costs make them less appealing for compute-intensive AI applications. As a result, many companies are opting to develop AI systems in-house. According to IDC, this trend is expected to contribute to a 10% increase in hardware infrastructure sales this year, fueled by the growing demand for AI solutions. ## The Case for Private Cloud Solutions Private clouds are built exclusively for a single organization. With data storage customized for a single company, private clouds assure higher levels of security. Another significant advantage is control. Private clouds allow organizations to manage their data configurations fully. Companies have the freedom to customize and optimize their infrastructure without external constraints, making private clouds the perfect solution for businesses that require greater control over their applications or handle sensitive data. In terms of costs, private clouds can initially seem more expensive than public clouds, especially considering the upfront investment in hardware and infrastructure management. However, as hardware prices continue to decrease due to commoditization, private clouds have become a more cost-efficient solution in the long run. Open-source private cloud solutions can further help mitigate these costs by reducing software expenses and providing flexible customization options. One downside of the private cloud is the setup and data migration process, which can be both costly and time-consuming. However, organizations such as [Kubermatic](/) offer cloud migration services, developing an exit strategy that meets each business's specific needs, thereby simplifying the transition to a private cloud environment. Furthermore, [Kubermatic Virtualization](/products/kubermatic-virtualization/) (KubeV) simplifies and improves the management of private cloud environments. It addresses some of the common challenges associated with private clouds, such as setup and data migration, by providing a more unified and flexible approach to cloud infrastructure. Recently, Kubermatic implemented KubeV for a [telecommunications client](/customers/telecommunications/) that was facing significant cost concerns after VMware's acquisition. By implementing KubeV, this telecommunications business was able to adopt a more flexible and cost-effective solution. They improved their customization and integration capabilities, reducing vendor lock-in and allowing integration with other products. This shift not only improved their operational efficiency but also offered better control and adaptability in managing their private cloud infrastructure. ## The Main takeaways For small companies or startups looking for on-demand scalability at a lower cost, the public cloud may be the ideal choice. However, at scale, the public cloud can become cost-prohibitive. If your enterprise deals with large data volumes, sensitive information, or needs greater control over data and configurations, a private cloud is more suitable. With companies like Kubermatic, the transition to a private cloud is smoother. By leveraging open-source components, KubeV can offer seamless cloud infrastructure entirely with Kubernetes. This approach simplifies operations and integrates Kubernetes with virtualized workloads, enhancing networking and storage capabilities. Kubermatic Virtualization (KubeV) ensures efficient cloud adoption and scalable management, streamlining your infrastructure. Get in touch with us! Visit a [customer story](https://www.kubermatic.com/customers/telecommunications/). --- ## Our Key takeaways from the 2024 Gartner® Hype Cycle™ for Infrastructure Platforms, 2024 - **URL:** https://www.kubermatic.com/blog/our-key-takeaways-from-the-2024-gartner-hype-cycle-for-infrastructure-platforms/ - **Date:** 2026-04-30 - **Description:** Discover the Emerging Trends in Infrastructure Platform Engineering. - **Categories:** Company - **Tags:** Announcements - **Authors:** Sebastian Scheele As we look toward the future of infrastructure and operations, it's clear that platform engineering is set to play a critical role in how organizations build and manage their technology systems. The Gartner® Hype Cycle™ for Infrastructure Platform predicts that, "By 2028, more than 50% of infrastructure and operations (I&O) organizations will have formed infrastructure platform engineering (IPE) groups, up from less than 25% in 2024." ## What is Infrastructure Platform Engineering (IPE)? Infrastructure Platform Engineering (IPE) is the practice of designing, building, and managing the foundational technology systems that support software development and IT operations within an organization. This field focuses on creating a scalable, efficient, and flexible infrastructure that enables development teams to deploy and manage applications more effectively. ## Trends in Infrastructure Platform Engineering Infrastructure Platform Engineering (IPE) is rapidly becoming a cornerstone for I&O teams. In the Priority Matrix for Infrastructure Platforms, 2024, Gartner classifies it as a Transformational technology, predicting 5 to 10 years for its Mainstream adoption. In the Gartner Hype Cycle, IPE is positioned at the "Peak of Inflated Expectations". The increasing focus on IPE is fueled by a series of crucial drivers. ## Key Growth Drivers: ### 1. Self-Service and Developer Empowerment Platform engineering empowers developers with self-service capabilities, allowing them to independently manage and deploy resources via Internal Developer Platforms. This shift enables IT teams to free up time and resources, allowing them to focus on strategic projects. ### 2. Automation and Standardization IPE eliminates repetitive, manual tasks involved in provisioning, configuring, and managing infrastructure. This automation accelerates processes and significantly lowers the risk of human error. As a result, organizations can scale faster, with automated systems effortlessly managing increased workloads. ### 3. Compliance and Security IPE ensures consistent policy enforcement and automated security updates across all infrastructure components. Additionally, the automation implemented by IPE improves risk management by minimizing human error and enabling faster incident response through automated protocols. ### 4. Enhanced API Utilization With APIs playing a crucial role in modern IT, platform engineering emphasizes utilizing robust, scalable control planes like those found in projects such as [kcp](https://www.kcp.io/). This approach provides developers with extensive tools for managing and extending application functionalities efficiently. ## Challenges and Recommendations To help enterprises overcome these challenges, Kubermatic has developed its own Internal Developer Platform. Visit [Kubermatic Developer Platform (KDP)](/products/kubermatic-developer-platform/) to learn more about how KDP can help your organization maximize developer productivity and accelerate innovation. **Gartner, Hype Cycle for Infrastructure Platforms, 2024, By Dennis Smith, 25 June 2024**. <br/> --- <small> <em> GARTNER and Hype Cycle are registered trademarks of Gartner, Inc. and/or its affiliates in the U.S. and internationally and are used herein with permission. All rights reserved. Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose. </em> </small> <br/><br/><br/><br/> --- ## Kubernetes-like Control Planes for Declarative APIs - A Practical Introduction to kcp - **URL:** https://www.kubermatic.com/resources/kubernetes-like-control-planes-for-declarative-apis-a-practical-introduction-to-kcp/ - **Date:** 2024-12-19 - **Description:** Our webinar on kcp explores the fundamental concepts of kcp, its usage of the KRM and how to publish and reconcile Kubernetes-like APIs to a multitude of users. # Kubernetes-like Control Planes for Declarative APIs - A Practical Introduction to kcp ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Join us on this webinar and gain insights into unlocking all new possibilities with kcp! In the Cloud Native world declarative APIs are ubiquitous, enshrined in the Kubernetes Resource Model (KRM). Kubernetes Operators are built around this concept and Platform Engineering, an emerging discipline in the ecosystem, often centers around it as well. This continued success of the KRM raises a question: Why not use the Kubernetes API without the intention to orchestrate containers? [kcp](https://www.kcp.io/), a CNCF Sandbox project, adds stronger multi-tenancy and additional API management capabilities on top of the Kubernetes API server code. It supercharges the KRM to be used as a generic control plane for any kind of declarative APIs. Our webinar on kcp explores the fundamental concepts of kcp, its usage of the KRM and how to publish and reconcile Kubernetes-like APIs to a multitude of users. Join us on this webinar and gain insights into unlocking all new possibilities with kcp! **Speaker: Marvin Beckers, Team Lead at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## How Kubernetes Aligns with the Bezos API Mandate - **URL:** https://www.kubermatic.com/blog/how-kubernetes-aligns-with-the-bezos-api-mandate/ - **Date:** 2026-04-30 - **Description:** Discover how the Bezos API Mandate is relevant for Kubernetes, why it still matters in modern software development, and what is the next step. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Mario Fahlandt In the early 2000s, a transformative mandate emerged from Amazon's headquarters, issued by its founder Jeff Bezos. This directive, now known as the Bezos API Mandate, has since become the bedrock of Amazon's and many other organizations' technological evolution, catalyzing the shift to cloud computing and redefining software development paradigms. Though the original document remains elusive, its impact and endurance in the tech world make it legendary. ## What is the Bezos API Mandate? In 2002, Jeff Bezos mandated that all Amazon teams must communicate with each other solely through service interfaces. The renowned Bezos API mandate set the foundation for modern API (Application Programming Interfaces) and microservice architecture that propels many of today's technological advancements. ### Why the Mandate Still Matters The original intent behind the mandate was simple yet profound: to ensure seamless communication and integration across various teams and systems. This paradigm is increasingly crucial in today's cloud-native world, where platforms must support diverse technological needs and offer scalable, efficient solutions. In an era increasingly focused on infrastructure as code, where changes are implemented through pull requests, it is vital to have clear and consistent interfaces. ## How is the Bezos API Mandate relevant for Kubernetes? The principles central to the Bezos API mandate - user-friendly, universally understandable interfaces - are perfectly exemplified by Kubernetes. For over ten years, Kubernetes has demonstrated the benefits of an API-driven architecture, ensuring reliable and scalable solutions for resource management. Its open and modular nature has benefited the community in various ways, having been vetted and quality-approved by a global community. ## The Role of APIs in Modern Platform Design In designing a modern platform, leveraging APIs for communication is crucial. By maintaining a workflow that includes requesting and building resources through well-defined API endpoints, platforms can facilitate easier creation and consumption of services by various users and personas. It is essential to establish standardized APIs that cater uniformly to all consumers, as this principle should underpin platform design. By offering a standardized API, platforms allow different users or providers to seamlessly adopt and extend these APIs, making it simpler to create and deliver new services in the future. Furthermore, a platform must be open and non-restrictive, yet adhere to these standards, accommodating the varied technological demands of stakeholders and supporting a wide range of user-requested technologies. ## What is the next Step for Platforms after Kubernetes The next logical step to follow the API first principles and to enable a unified pattern across your platform is to utilize the best of part of Kubernetes - its flexible APIs. KCP, a CNCF Sandbox project, can help with this, as it gives you the capabilities to create a horizontally scalable control plane for Kubernetes-like APIs. It acts as a framework for centrally offering APIs using multi-tenant operators. Using this project as a baseline, Kubermatic is building a Developer Platform to enable an easy-to-use and extendable platform. This will enable platform teams to focus on the platform, while also allowing Service providers to easily offer services there through a unified API and a well-defined standard. ## Conclusion: Embrace the API Era The principles of open communication and standardization outlined in the Bezos API mandate have had a significant and lasting impact on contemporary platform design. As we look to the future, embracing this API-driven world offers businesses unprecedented opportunities for growth and innovation. The question remains: are you ready to harness the transformative power of APIs for your own digital journey? ## Learn more - Lern more about [Why We Decided to Support External Kubernetes Clusters Via API at Kubermatic](/blog/why-we-decided-to-support-external-kubernetes-clusters-via-api/) - Discover how you can build your private cloud entirely with [Kubernetes with KubeV](/products/kubermatic-virtualization/) --- ## Kubernetes 1.32 is here! - **URL:** https://www.kubermatic.com/blog/kubernetes-1-32-is-here/ - **Date:** 2026-04-30 - **Description:** The Kubernetes 1.32 release is here! In our blog post, we highlight major improvements and show how and when you benefit from them. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Joana Figueiredo Only a couple of days are left in the Kubernetes 10th anniversary year. This release, codenamed "Penelope", celebrates Kubernetes' 10th anniversary and reflects on the continuous weaving of its features, much like Penelope's tapestry. Let's take a look at its main features. This release consists of 44 enhancements in total, specifically: - 13 enhancements have graduated beta features to stable - 12 enhancements have graduated alpha features to beta - 19 enhancements have introduced new alpha-level features In this blog post, we asked three of our engineers who are extensively involved in the [Kubernetes project](https://github.com/kubernetes/kubernetes), to share their key highlights. For a complete overview of all the changes, we recommend you check out the [official release announcement](https://kubernetes.io/blog/2024/12/11/kubernetes-v1-32-release/) and the [1.32 changelog](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.32.md). [Marko Mudrinić](https://github.com/xmudrii) is Tech Lead of SIG K8s Infra, a CNCF Ambassador and Kubernetes Release Engineering Subproject Lead - "My highlight of the 1.32 release is the Single Process OOM Killing. This addition allows for more granular control over Out-Of-Memory (OOM) situations. With the singleProcessOOMKill flag, you can configure kubelet to only kill the single process exceeding memory limits within a container, preventing unnecessary disruptions to other processes in the same container." [Koray Oksay](https://www.linkedin.com/in/korayoksay/) is a CNCF Ambassador and part of SIG K8s Infra - "The outstanding feature for me is Auto-remove PersistentVolumeClaims (PVCs) for StatefulSets. This feature simplifies storage management for StatefulSets. Kubernetes now automatically removes PVCs created by StatefulSets when they're no longer needed. This ensures data persistence during updates and node maintenance while reducing the risk of orphaned PVCs cluttering your storage." [Mario Fahlandt](https://www.linkedin.com/in/mfahlandt/) is a Co-Chair of SIG ContribEx, also part of SIG K8s Infra and a CNCF Ambassador - "I will go with the enhancements to Dynamic Ressource Allocations - the whole topic is an ever present topic especially with more requirements for Kubernetes to work well on specific hardware. These improvements will increase the flexibility and efficiency of resource allocation for workloads that require specific hardware, such as GPUs, FPGAs, and network adapters. Structured Parameter Support, a key feature of Dynamic Resource Allocation (DRA), has been upgraded to beta. This improvement enables the kube-scheduler and Cluster Autoscaler to simulate resource claim allocations directly. They can predict if resource requests can be met based on the current cluster state without committing to allocations. By removing the need for a third-party driver for validation, this feature streamlines resource distribution planning and enhances scheduling and scaling efficiency." ## Beyond these highlights, v1.32 offers a range of other improvements, including: **Memory Manager Goes GA** The memory manager has officially been released for General Availability (GA). This feature will improve memory allocation for containerized applications. The GA release primarily includes bug fixes, internal refactoring, and improvements in observability, such as better metrics and logging. **Bound service account token improvement** This feature has graduated to stable. The node name is now included in the service account token claims, allowing users to use this information during authorization and admission (ValidatingAdmissionPolicy). This improvement further keeps service account credentials from being a privilege escalation path for nodes. **Support to size memory-backed volumes** This new feature allows the dynamic sizing of memory-backed volumes according to Pod resource limits, optimizing overall node resource utilization. **Structured authorization configuration** In Kubernetes 1.32, multiple authorizers can now be configured in the API server to allow for structured authorization decisions. ## API removals There was one API removal in Kubernetes 1.32. The `flowcontrol.apiserver.k8s.io/v1beta3` API version of FlowSchema and PriorityLevelConfiguration has been removed. To prepare for this, you can rewrite client software to use the `flowcontrol.apiserver.k8s.io/v1` API version, which has been available since v1.29. All existing persisted objects are accessible via the new API. Notable changes in `flowcontrol.apiserver.k8s.io/v1beta3` include that the PriorityLevelConfiguration `spec.limited.nominalConcurrencyShares` field only defaults to 30 when unspecified, and an explicit value of 0 is not changed to 30. For more information, refer to the [API deprecation guide](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-32). ## Withdrawal of the old DRA implementation In Kubernetes 1.32, the handling of DRA will be changed by removing the original implementation's code. KEP [#4381](https://github.com/kubernetes/enhancements/issues/4381) will now be the "new" base functionality. This removal will allow Kubernetes to handle new hardware requirements and resource claims more predictably, bypassing the complexities of back-and-forth API calls to the kube-apiserver. ## Learn more - [Official Kubernetes 1.32 release announcement](https://kubernetes.io/blog/2024/12/11/kubernetes-v1-32-release/) - [Kubernetes 1.32 changelog](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.32.md) --- ## Internal Developer Platforms - **URL:** https://www.kubermatic.com/topics/internal-developer-platforms/ - **Date:** 2025-01-06 - **Description:** Learn all about Internal Developer Platforms (IDP), Kubernetes Developer Platforms (KDP), their advantages and drawbacks # Internal Developer Platforms ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Jump To Section [What is an Internal Developer Platform?](#what-is-an-internal-developer-platform) [What is a Kubernetes Developer Platform?](#what-is-a-kubernetes-developer-platform) [What are the advantages of a Kubernetes Developer Platform?](#what-are-the-advantages-of-a-kubernetes-developer-platform) [What is the Kubermatic Developer Platform (KDP)?](#what-is-the-kubermatic-developer-platform-kdp) [How does KDP benefit developers and organizations?](#how-does-kdp-benefit-developers-and-organizations) ## What is an Internal Developer Platform? An Internal Developer Platform (IDP) is a customized set of tools, services, and processes created within an organization. IDPs provide self-service capabilities to developers, enabling them to deploy, manage, and monitor applications without depending on operations teams. IDPs are commonly implemented to improve developer experience by automating parts of the software development lifecycle, reducing cognitive load, and lowering the complexity of operational processes. Internal Developer Platforms simplify these processes by integrating infrastructure components - such as CI/CD pipelines, monitoring, security, and cloud resources - into a cohesive interface. This interface ensures developers have the right tools to build, deploy, and scale applications, reducing bottlenecks and fostering a culture of collaboration across development teams. **Kubernetes** [Kubernetes](/topics/kubernetes/), also known as k8s, is an open-source container orchestration platform that automates the deployment, scaling, and operation of application containers. It provides a consistent and flexible environment for application deployment, whether in public clouds, on-prem, or edge infrastructures. Additionally, Kubernetes manages the allocation of storage and [persistent volumes](/blog/keeping-the-state-of-apps-4-persistentvolumes-and-persistentvolum/). ## What is a Kubernetes Developer Platform? Kubernetes Developer Platforms (KDPs) were created to mitigate the complexity of Kubernetes. A KDP is essentially an Internal Developer Platform that is built on top of Kubernetes. KDPs use Kubernetes as the foundational layer to make it easier for developers to build and deploy applications without needing extensive knowledge about the underlying infrastructure. Kubernetes Developer Platforms can be viewed as a developer-friendly layer that simplifies interactions with underlying resources. ## What are the advantages of a Kubernetes Developer Platform? **1. Improved Developer Productivity:** Kubernetes Developer Platforms (KDPs) were created to mitigate the complexity of Kubernetes. A KDP is essentially an Internal Developer Platform that is built on top of Kubernetes. KDPs use Kubernetes as the foundational layer to make it easier for developers to build and deploy applications without needing extensive knowledge about the underlying infrastructure. **2. Scalability:** Kubernetes automatically manages the scaling of application components based on demand, ensuring that resources are used efficiently and applications remain responsive during periods of high load. **3. Portability and Consistency:** KDPs provide a consistent operational environment, allowing applications to be easily moved across different infrastructures - whether on-premises, in public clouds, or with hybrid setups. This portability is crucial for businesses to avoid vendor lock-in and leverage multiple cloud environments without needing to rewrite or modify application architectures. **4. Reduced downtime and faster healing:** Kubernetes features automated failover and self-healing capabilities. If a component fails, Kubernetes automatically reschedules workloads and restarts containers as needed - minimizing downtime and ensuring applications remain available even in the event of component failures. **5. Cost Efficiency:** Kubernetes efficiently manages and allocates computing resources, optimizing performance and preventing over-provisioning. This leads to lower operational costs, as businesses can avoid unnecessary expenses associated with idle resources while ensuring optimal performance levels. **6. Security and Compliance:** Kubernetes platforms incorporate robust security features, such as network policies, role-based access control, and secrets management, which are essential for securing applications and ensuring compliance with industry standards. These integrated security measures help ensure that applications meet necessary security and compliance standards. ## What is the Kubermatic Developer Platform (KDP)? [KDP](/products/kubermatic-developer-platform/) is a Kubernetes-powered internal developer platform that automates service management, enhances productivity, and accelerates innovation by allowing developers to deploy and manage services through a centralized service catalog. Built with scalability and multi-tenancy, KDP is designed for organizations with complex development needs and large-scale operations. Kubermatic developed KDP to address common development bottlenecks, such as manual service creation, long wait times, and fragmented service management. KDP empowers development teams to work more autonomously, reducing friction in the development process, and fostering faster innovation across the organization. ## How does KDP benefit developers and organizations? KDP provides instant service deployment, reducing downtime and boosting productivity. For organizations, this translates to cost savings, streamlined operations, and a scalable, flexible platform that aligns with their governance needs. KDP’s automation and multi-tenancy capabilities enhance collaboration and efficiency organization-wide. --- ## Can You Put a Price Tag on Open Source? - **URL:** https://www.kubermatic.com/resources/can-you-put-a-price-tag-on-open-source/ - **Date:** 2024-12-09 - **Description:** In this talk, Bob and Mario will discuss the many benefits individuals and companies can achieve by contributing to open source and guide you through the first steps to becoming a contributor. # Can You Put a Price Tag on Open Source? ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Mario's and & Bob's talk at KubeCon NA 2024 Earlier this year, the Harvard Business School released the paper titled “The Value of Open Source Software”, estimating the worldwide value of OSS at 8.8 trillion. On average, it would cost companies at least 3.5x more to develop similar projects internally. Yet, many organizations and engineers struggle to understand or realize this kind of value from contributing to these projects. In this talk, Bob and Mario will discuss the many benefits individuals and companies can achieve by contributing to open source and guide you through the first steps to becoming a contributor. They will also cover how to develop a lightweight open source strategy and convince your organization that an open source first approach can yield great returns. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Understanding KKP Multi-Cloud Application Platform - **URL:** https://www.kubermatic.com/blog/understanding-kkp-multi-cloud-application/ - **Date:** 2026-04-30 - **Description:** In this blog post, we will explore how KKP automates Kubernetes deployment and simplifies multi-cloud cluster management. - **Categories:** Products - **Tags:** KKP - **Authors:** Mario Fahlandt In the rapidly evolving world of cloud computing, managing Kubernetes deployments across multiple environments can be challenging for IT teams. In fact, according to [Gartner](https://www.gartner.com/en/information-technology/topics/business-value-of-it), **organizations spend 70% of their IT resources to maintain current operations, leaving only 30% dedicated to innovation**. The KKP Multi-Cloud Application addresses this unnecessary complexity. KKP simplifies multi-cloud cluster management and automates Kubernetes deployment across various cloud providers. ## What is KKP? The Kubermatic Kubernetes Platform (KKP) is an advanced multi-cloud and on-prem cluster management tool for [Kubernetes](https://kubernetes.io/). KKP supports various [cloud providers](https://docs.kubermatic.com/kubermatic/v2.26/architecture/supported-providers/) - including AWS, Google Cloud Platform (GCP), and Microsoft Azure, as well as on-premises environments like OpenStack, VMware, and even bare-metal setups. This versatility ensures businesses can easily deploy and manage their Kubernetes resources in any multi-cloud environment. ## Key Features of KKP ### 1. Comprehensive Multi-Cloud Support KKP is engineered to function smoothly across different clouds and environments. For those looking to embrace cloud-native hypervisor solutions, KKP can also run on top of [KubeVirt](https://docs.kubermatic.com/kubermatic/v2.26/architecture/concept/kkp-concepts/applications/default-applications-catalog/kubevirt/), providing a cloud-native virtualization route. ### 2. Diverse OS Compatibility Depending on the environment, KKP supports a [variety of operating systems](https://docs.kubermatic.com/kubermatic/v2.26/architecture/compatibility/os-support-matrix/), including Rocky Linux, Flatcar, Red Hat Enterprise Linux, and Ubuntu, among others. This allows for a flexible deployment strategy tailored to specific organizational needs. ### 3. Automated Cluster Deployment Kubermatic offers various methods to create Kubernetes Clusters. There is a centralized GUI that can be used to easily create clusters across providers. As an alternative method, it is also possible to create clusters following GitOps and Infrastructure as Code (IaC) principles by utilizing the REST API or interacting with CRDs. The lifecycle of those clusters is also managed by KKP and it utilizes machine-controller - an API adoption of cluster API - to manage the nodes in the various environments seamlessly. ### 4. All-in-one Suite One of the best aspects of KKP is that it is an all-in-one suite. It includes centralized monitoring, logging, and alerting, as part of the whole stack. Aligned with our open-source ethos, KKP offers centralized management that supports any OS, including tools like Grafana, Prometheus, Loki, and Cortex. <img src="/static/kkp-multiclout-chart.png" alt="KKP multiclout chart" width="786" height="686" loading="lazy"> ### 5. Centralized Access Management KKP integrates seamlessly with any OpenID Connect (OIDC) provider for secure and easy access management. This integration ensures that only authorized users can access the platform or specific Kubernetes clusters. ### 6. Cost Optimization and Metering KKP's metering and cost optimization features allow its users to easily understand the financial implications of Kubernetes deployments. ### 7. Open Source Kubermatic Kubernetes Platform (KKP) follows an open core model. Businesses can use the open core license model, or choose an enterprise model for advanced functionalities targeting robust enterprise needs. ## Kubermatic Kubernetes Platform Infrastructure KKP's architecture is optimized for multi-tenancy and multienvironment deployments. KKP uses a unique approach, where Kubernetes runs inside Kubernetes, resulting in superior scalability and flexibility. A central management cluster oversees various components and workloads, with the virtualized control planes facilitating an efficient resource allocation. This [architecture model](https://docs.kubermatic.com/kubermatic/v2.26/architecture/) also allows organizations to efficiently manage resources by scaling them according to need. With KKP, cluster management is also simplified. **KKP supports the deployment of hundreds, even thousands, of clusters via seed clusters**, enabling organizations to stretch and scale their operations virtually without limits. This flexibility not only optimizes resource use but also significantly reduces cluster management overhead costs. With KKP's approach, the more clusters our users manage, the more resources they conserve, requiring only a fraction of the resources compared to traditional methods. ## KKP's self-serving platform KKP introduces a self-service platform ethos, empowering users to easily create and deploy clusters. KKP's [application catalog](https://docs.kubermatic.com/kubermatic/v2.26/architecture/concept/kkp-concepts/applications/) offers a standardized set of applications ready for deployment across various cloud environments. KKP is capable of fully supporting Hybrid, on-premise, or full cloud architectures, in multiple clouds at the same time. ## Conclusion Kubermatic Kubernetes Platform stands at the forefront of multi-cloud cluster management, offering an automated, seamless, and efficient way to handle Kubernetes deployment and management. KKP combines advanced features with a user-friendly interface, supporting modern enterprises' need for agility, flexibility, and cost-efficiency in their cloud-native strategies. With KKP, businesses can harness the full power of Kubernetes across any cloud environment with confidence and control. ## Learn more - Learn more about KKP in our [documentation](https://docs.kubermatic.com/kubermatic/v2.26/architecture/). - Request your [free demo](/demo/) and learn how KKP can automate your Kubernetes Clusters management. --- ## Einfach Komplex - Kubernetes with Mario Fahlandt - **URL:** https://www.kubermatic.com/resources/einfach-komplex-kubernetes-with-mario-fahlandt/ - **Date:** 2024-12-09 - **Description:** Discover valuable insights into Kubernetes and the world of container orchestration with Mario Fahlandt in this episode of Einfach Komplex. # Einfach Komplex - Kubernetes with Mario Fahlandt ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ![](/static/einfach-komplex-kubernetes-with-mario-fahlandt_hu_a1dfb2eedf3dcf1a.jpg) Podcast ## Learn more about Kubernetes with Mario Fahlandt in the Podcast Einfach Komplex Let’s talk about Kubernetes and container orchestration with Mario Fahlandt, Customer Delivery Architect at Kubermatic and an active contributor to the Kubernetes project! In today’s software development landscape, it is crucial to design applications that are flexible and scalable. This is where Kubernetes excels: it ensures that containerized applications run reliably and can automatically scale as needed. Additionally, Kubernetes reduces the manual effort involved in managing containers, making it indispensable for complex and dynamic IT environments. Thanks to features such as self-healing, automatic rollbacks, and load balancing, it has become the de facto standard tool for modern IT infrastructures. Listen to it to not miss any valuable insights and learn how you can drive your business forward. [Listen](https://open.spotify.com/episode/2L4SR5sWyuBncwN6uUbMga) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## A Sneaky Peek at Kubermatic Developer Platform (KDP): Empower Developers, Accelerate Innovation - **URL:** https://www.kubermatic.com/blog/sneaky-peek-at-kubermatic-developer-platform-empower-developers-accelerate-innovation/ - **Date:** 2026-04-30 - **Description:** Elevate your development operations with the Kubermatic Developer Platform (KDP), based on CNCF Sandbox project KCP. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Sebastian Scheele The future of developer productivity is hiding just around the corner, and we're giving you an exclusive sneaky peek at the Kubermatic Developer Platform (KDP). No smoke, no mirrors — just pure, unfiltered power designed to accelerate innovation while taking the complexity out of infrastructure management. Ready to dive in? Let's pull back the curtain on KDP and show you why it's about to become your favorite new tool for developer autonomy, collaboration, and serious efficiency gains. ## Why Should You Care About Internal Developer Platforms? If you've ever felt bogged down by slow, cumbersome infrastructure management or had to wait hours (or days!) for a service to be deployed, then you already know the pain KDP is here to solve. **Internal Developer Platforms (IDPs)** are changing the game, creating a seamless layer between development teams and infrastructure. They enable developers to focus on what they do best—coding and building amazing products—while the platform automates the nitty-gritty of deployment and management. But let's get real—what does that mean for you? KDP is built specifically for **developers**, **platform teams**, and **service owners** looking to remove blockers, reduce time-to-market, and automate the painful parts of service deployment. ## Why Kubermatic Developer Platform (KDP) is Different Here's where KDP stands out in the crowd. Instead of just being another tool that promises to "streamline" operations, KDP does it by harnessing the raw power of **Kubernetes**. Yes, that Kubernetes — the open-source juggernaut of container orchestration. At KDP's core, Kubernetes APIs allow developers to work in cloud-native environments while keeping infrastructure management abstracted but accessible. Let's be clear: KDP isn't here to add to the noise. It's here to give you a single, easy-to-use control point that: - **Automates service instance creation** — turning hours of manual labor into seconds of automation. - **Centralizes service management** — one catalog, endless possibilities, no delays. - **Scales effortlessly** — whether you're managing five services or five thousand, KDP grows with you. ## What's Hiding in KDP? (Spoiler Alert: Cool Features) You didn't think we'd just tease you with KDP's benefits without spilling the technical beans, did you? Here's a peek at the features we're particularly proud of: - **Multi-Tenancy & Modularity**: Need to manage multiple teams in one environment? No problem. KDP isolates teams securely while providing flexibility through a modular design that adapts to your needs. - **Kubernetes-Powered Integration**: Seamlessly integrate your workflows with cloud-native infrastructures, all thanks to the power of Kubernetes APIs. - **Centralized Service Catalog**: Think of it like a menu—everything you need to deploy or manage is at your fingertips, without the annoying wait times of traditional ticketing systems. Need it? Launch it. Done. - **Automated Service Instance Creation**: Stop wasting precious hours on manual deployments. KDP's automation engine reduces the time it takes to deploy services from hours to seconds. Now, that's what we call efficiency! - **Customizable Platform**: Not every organization works the same way. KDP can be tailored to fit your internal policies, workflows, and governance structures so everything aligns perfectly. ## What Does This Mean for Developers, Platform Teams, and Service Owners? In short: **Speed**, **simplicity**, **and power**. KDP allows you to focus on what really matters — innovation. - For **developers**, KDP means faster access to the tools and services you need without jumping through hoops. No more waiting on infrastructure. Just create, deploy, and scale. - For **platform teams**, it means automation that frees you from the burden of keeping the platform up and running, allowing you to focus on scaling and improving services. - For **service owners**, it means having a clear, centralized control point to manage and deploy services with consistency and fewer errors. ## Use Cases: Where Can You Sneak KDP into Your Workflow? Whether you're running a startup or managing enterprise-level IT infrastructures, KDP fits seamlessly into a variety of environments: - **Enterprise IT Management**: Centralize service management across large teams and ensure top-notch security and compliance. - **Tech Startups**: Automate deployment and management tasks so you can focus on innovating, not maintaining. - **Cloud-Native Development**: Need to scale while transitioning to the cloud? KDP has you covered, offering consistent control over your containerized services, no matter how complex your operations become. ## The Sneaky Bottom Line KDP isn't just another tool. It's the platform that gives you back your time, enhances your operations, and empowers your developers to innovate without the infrastructure headaches. By leveraging Kubernetes APIs and built-in automation, KDP makes service deployment and management faster, more secure, and infinitely scalable. So there it is—your sneaky peek into the Kubermatic Developer Platform. It's time to take control, accelerate your development workflows, and empower your teams like never before. Want more? Visit our KDP documentation or check out the CNCF Sandbox project KCP to dig deeper into what powers KDP. **Ready to stop managing and start building? Contact us today** to learn how KDP can transform your organization's developer experience. KDP is scheduled for general availability in January 2025, so get ahead and talk to us now. --- ## Meet KubeOne 1.9 - Supporting Kubernetes 1.31 - **URL:** https://www.kubermatic.com/blog/meet-kubeone-1-9-supporting-kubernetes-1-31/ - **Date:** 2026-04-30 - **Description:** The KubeOne 1.9 release introduces support for Kubernetes 1.31 and Ubuntu 24.04, offers a KubeOne UI Technical Preview, and includes the ability to create custom kubeconfig files. - **Categories:** Products - **Tags:** KubeOne - **Authors:** Marko Mudrinić We're happy to announce that KubeOne 1.9 is now available! KubeOne is our open-source cluster lifecycle management tool to automate cluster deployment and management in your preferred on-prem, edge, or cloud environment. While this update focuses on essential improvements rather than a wide array of changes, it strengthens KubeOne and sets the stage for exciting developments coming next. Here's what you need to know about the newest release: **Support for Kubernetes 1.31**: We're always doing our best to ensure support for the newest Kubernetes releases. We've extended KubeOne's capabilities to support [Kubernetes 1.31](https://kubernetes.io/blog/2024/08/13/kubernetes-v1-31-release/), enabling you to take advantage of the newest features and improvements. This involves updating all components deployed by KubeOne to the latest versions, such as CNIs and other add-ons. This approach ensures all components are compatible with the latest Kubernetes version, allowing you to enjoy all the latest features and fixes. **Support for Ubuntu 24.04**: This release comes with support for [Ubuntu 24.04](https://ubuntu.com/blog/upgrade-your-desktop-ubuntu-24-04-lts) for the control plane nodes, the static worker nodes, and the nodes managed by our machine-controller. Additionally, Ubuntu 24.04 is now the default operating system - all Terraform configs are updated to Ubuntu 24.04, and the machine-controller will deploy Ubuntu 24.04 worker nodes if Ubuntu is selected as the operating system. **Changes in Support Policy**: We've made several adjustments to our support policy. This KubeOne release supports Kubernetes versions starting with Kubernetes v1.29. If you're using an older Kubernetes version, you'll need to use prior KubeOne versions (according to the [Compatibility Policy](https://docs.kubermatic.com/kubeone/v1.9/architecture/compatibility/supported-versions/)) to upgrade to Kubernetes v1.29 before upgrading to KubeOne v1.9. Furthermore, KubeOne v1.9 has discontinued support for CentOS, as CentOS has reached its end of life. If you still use CentOS, we strongly recommend migrating to another supported operating system. **KubeOne UI Technical Preview**: With this release, we're introducing a technical preview of what we call “the KubeOne UI”. At the moment, this is a read-only UI, allowing you to monitor the cluster status, focusing mainly on the health of the control plane nodes, components, and worker nodes. Looking ahead, we plan on adding additional features, especially to facilitate cluster management via this UI. We greatly value your feedback, so if there's anything you'd like to see in the UI, please [create an issue in the KubeOne repository](https://github.com/kubermatic/kubeone/issues/new?template=feature-request.md). <img src="/static/kubeone-1-9-img-1.jpg" alt="KubeOne UI Technical Preview" width="800" height="392" loading="lazy"> **Manage kubeconfigs using `kubeone kubeconfig generate` subcommand**: Shipping the generated-by-default kubeconfig file has never been a good security practice. It's irrevocable, long term and has super admin permissions. With the latest release of KubeOne 1.9, generating a custom kubeconfig file has never been easier. Combining Kubernetes' RBAC and `kubeone kubeconfig generate`, you can generate a kubeconfig tailored to your needs and that's much safer to distribute to other cluster users. <img src="/static/kubeone-1-9-img-2.jpg" alt="kubeone kubeconfig generate" width="800" height="155" loading="lazy"> **Exciting Future Prospects**: Looking ahead, we're excited to announce several new features planned for our upcoming release, KubeOne 1.10. We're eager to introduce a new KubeOneCluster API version, designed to deliver a groundbreaking cluster management experience. We're also exploring the possibility of adding new commands to further simplify the cluster management process, though these are still in the planning phase. We hope the new release of KubeOne helps you operate your Kubernetes clusters with ease and flexibility! For more details, please visit the [changelog](https://github.com/kubermatic/kubeone/blob/main/CHANGELOG/CHANGELOG-1.9.md). Of course, we are always happy to learn about your thoughts and feedback on our cloud-native projects. Just ping us on our {{< slackjoinlink "Community Slack" >}} or on [GitHub](https://github.com/kubermatic/kubeone). ## Learn more Visit the [instructions for upgrading](https://docs.kubermatic.com/kubeone/v1.9/tutorials/upgrading/upgrading-from-1.8-to-1.9/). Read the complete [changelog](https://github.com/kubermatic/kubeone/blob/main/CHANGELOG/CHANGELOG-1.9.md). For more details, visit the [KubeOne documentation](https://docs.kubermatic.com/kubeone/v1.9/). --- ## Kubermatic Developer Platform - **URL:** https://www.kubermatic.com/products/kubermatic-developer-platform/ - **Date:** 2026-03-30 - **Description:** KDP enables the creation and management of services backed by a centralized service catalog. KDP streamlines processes, reducing downtime, improving productivity, and allowing your team to focus on what truly matters. # Kubermatic Developer Platform (KDP) Empower Developers and Accelerate Innovation [Contact Sales](/contact-sales/) [KDP Whitepaper](/whitepaper-kdp-empower-developers-accelerate-innovation/) [KDP Solution Brief](/solution-brief-empower-developers-and-accelerate-innovation-with-kubermatic-developer-platform/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) **Maximize developer productivity and accelerate innovation with Kubermatic Developer Platform (KDP). Powered by Kubernetes API, KDP enables the creation and management of services backed by a centralized service catalog.** **Powered by CNCF’s Sandbox Project kcp.** [Learn more about kcp](/kcp/) ## Build an Empowered, Efficient Development Team ### Without KDP - **Manual Service Deployment**:Long wait times due to manual processes and ticketing systems - **Fragmented Tools**:Lack of centralized service management creates inefficiencies - **Inconsistent Operations**:Teams struggle with varying practices across departments - **Reduced Innovation**:Long wait times limit developers' ability to focus on innovation - **High Operational Overhead**:Manual infrastructure management drains resources ### With KDP - **Automated One-Click Service Instance Creation**:Near-zero wait time for new instances - **Unified Service Catalog**:Centralized access to all services maximizing collaboration and efficiency - **Unmatched multi-tenancy**:Secure access for multiple development teams - **Customizable and Adaptable**:Aligns to culture, policies and internal governance and structure - **Native Kubernetes APIs**:Seamless integration with operators and Crossplane ## Supercharge Productivity #### Powered by Kubernetes, based on CNCF KCP Maximize developer productivity and accelerate innovation with Kubermatic Developer Platform (KDP). Powered by Kubernetes API and based on [CNCF Sandbox project KCP](https://www.cncf.io/projects/kcp/), our cutting-edge internal developer platform enables the seamless creation and management of services backed by a centralized catalog. With unparalleled multi-tenancy, development teams can access and instantly deploy services, taking collaboration and efficiency to new heights. Play Video ## Benefits Your Entire Development Organization ![](/static/kdp-illustration-1.svg) ### Service Owners Effortlessly spin up services into a centralized service catalog accessible to your entire development organization. ![](/static/kdp-illustration-2.svg) ### Platform Team Transform service delivery and management with the Kubermatic Developer Platform (KDP). Powered by Kubernetes. ![](/static/kdp-illustration-3.svg) ### Developers Instantly deploy services and free yourself from manual tasks so you can focus on building and innovating faster. ## Why Kubermatic Development Platform? ![](/images/icons/admin-icon.svg) ### Powered by Kubernetes KDP leverages the power of Kubernetes APIs, enabling the platform to provide seamless integration with cloud-native environments. This integration ensures that KDP can support many use cases, from small startups with complex IT infrastructures to large enterprises. ![](/images/icons/transformation.svg) ### Cost Savings and Efficiency By automating the service instance creation process, KDP eliminates the need for manual ticketing systems, saving valuable time for both developers and platform owners and leading to significant cost reductions. ![](/static/gear-icon.svg) ### Accelerated Innovation Offering a comprehensive service catalog that's easily accessible across the organization, KDP enables seamless collaboration, giving developers more time and freedom to innovate. [Contact Sales](/contact-sales/) --- ## Contact Sales - **URL:** https://www.kubermatic.com/contact-sales/ - **Date:** 2024-11-05 - **Description:** Contact us to get information about our products and services. Fill in the form on our website for a quick response to all your queries. # Contact Sales We are happy to connect! Let’s talk about your goals and we will let you know how we can drive your business forward. ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Contact Sales We’ve got you covered. Let us know how we can help you! If our form couldn't load correctly – This can have multiple reasons like ad blocker, not accepted cookies, JavaScript deactivated. However, you can still get in touch with us! Simply click on the button below, and you'll be able to submit the form and reach out to us for any inquiries or assistance you need. [Open form](https://share.hsforms.com/1fkMxeszEQfWZl-goKjoe1w2piu8) ![](/static/typewriting-machine.jpg) ## Global Leaders Work With Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) [Read Customer Stories](/customers/) --- ## Simplifying Kubernetes Management for the Berlin Institute of Health (BIH) - **URL:** https://www.kubermatic.com/customers/bih/ - **Date:** 2026-06-23 - **Description:** Discover how bioinformaticians at the Berlin Institute of Health optimized Kubernetes cluster management with Kubermatic Kubernetes Platform, enhancing research efficiency and scalability. # Simplifying Kubernetes Management for the Berlin Institute of Health (BIH) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## The Challenge ### The time-consuming task of Managing Kubernetes Clusters Bioinformaticians at the Berlin Institute of Health (BIH) faced growing demands for Kubernetes clusters to support their research projects. The de.NBI Cloud already enabled quick cluster creation. However, managing and updating these clusters took up valuable time that could have been spent on research. ## The Solution ### Automating tasks with KKP Collaborating with the cloud team at BIH at Charité, SVA experts recommended the Kubermatic Kubernetes Platform (KKP). KKP enabled the creation of a scalable central control plane, which unlocked flexible scalability. It also seamlessly integrated different cloud providers - in this case, the OpenStack-based cloud at BIH. ## The Impact ### Cluster Management with just a click With KKP, the end users (bioinformaticians) no longer need in-depth knowledge of the infrastructure to manage their clusters. They can simply select the required resources and node types for their clusters. With KKP, even updates to the clusters can be carried out with just a click, freeing them to focus on innovative research without the technical hassles. ![Tablet showing heart rate measurements](/static/tablet-with-heart-bg.jpg) ![BIH white logo](/static/bih-white-logo.svg) The mission of the Berlin Institute of Health (BIH) is medical translation: findings from biomedical research are transferred into new approaches for personalized prediction, prevention, diagnostics, and therapy. Conversely, observations in everyday clinical practice lead to new research ideas. BIH was founded in 2013 and is 90 percent funded by the Federal Ministry of Education and Research (BMBF), and 10 percent by the State of Berlin. The founding institutions Charité - Universitätsmedizin Berlin and Max Delbrück Center were independent members of BIH until 2020. Since 2021, BIH has been integrated into Charité as a so-called third pillar, and the Max Delbrück Center is a privileged partner of BIH. > A key advantage is that the Kubernetes control plane, or master nodes, are centrally hosted rather than set up as three virtual machines for each cluster. Once projects have access to KKP, users can fully manage the clusters themselves, making it extremely user-friendly. Harald Wagener, Group Leader Cloud, AG Eils, BIH --- ## Steering the Roadblocks: Strategic Paths for CIOs After Broadcom's VMware Acquisition - **URL:** https://www.kubermatic.com/solution-brief-strategic-paths-for-cios-after-broadcoms-vmware-acquisition/ - **Date:** 2026-04-28 - **Description:** Get actionable insights for managing IT infrastructure, ensuring business continuity, and leveraging emerging technologies. Includes a roadmap for CIOs to assess current dependencies, explore alternative technologies, and optimize existing infrastructure. # Steering the Roadblocks: Strategic Paths for CIOs After Broadcom’s VMware Acquisition ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Overview Broadcom’s acquisition of VMware, announced on November 22, 2023, has led to significant changes in VMware’s product offerings, licensing models, and partner programs. This development poses substantial challenges and potential disruptions for organizations relying on VMware for their IT infrastructure. As a result, CIOs must proactively address these changes to maintain operational stability and cost-effectiveness while preparing for potential future shifts in their technology strategies. ## Key Impacts of the Acquisition ### Discontinuation of Perpetual Licenses Effective December 11, 2023, Broadcom has ceased the sale of perpetual licenses for VMware products, transitioning all customers to a subscription-based model. This shift has led to concerns about increased costs and reduced flexibility. CIOs must conduct an immediate and thorough inventory of existing VMware infrastructure to understand the financial and operational implications of this licensing change. ### Changes to Partner and OEM Agreements Broadcom has terminated VMware’s OEM agreements with vendors such as Dell, HPE, and Lenovo, replacing them with a new program that removes legacy discounts. Additionally, VMware’s partner programs have been restructured, with some channel partners losing their reseller status. Organizations must engage with Broadcom and their channel partners to understand the impact of these changes on their existing agreements and plan accordingly. ### Potential Cost Increases Many organizations have reported significant cost increases, with some experiencing price hikes of 2x to 5x for VMware renewals. This is partly due to the shift to subscription-based licensing and changes in product bundles. CIOs should negotiate with Broadcom or authorized partners to explore potential discounts or flexible payment options, particularly for large deployments. ## Navigating VMware Migration in 5 Steps To navigate the changes brought about by Broadcom’s acquisition of VMware, CIOs should consider the following strategic actions: ![](/static/centralized-icon-gold-pink.svg) ### 1. Engage with Broadcom and Channel Partners Establish open lines of communication with Broadcom account teams and channel partners to ensure mutual understanding of risks, goals, and expectations. This engagement is crucial for negotiating favorable terms and understanding the full impact of the acquisition on your organization. ![](/static/chart-gold-pink.svg) ### 2. Assess and Optimize VMware Infrastructure Conduct a comprehensive assessment of your VMware infrastructure to identify underutilized resources and inefficiencies. Increase virtual machine density and optimize the utilization of current clusters to manage costs effectively, particularly given the new subscription licenses are priced per CPU core. ![](/static/cloud-icon-gold-pink.svg) ### 3. Explore Alternative Solutions Evaluate alternative hypervisors and virtualization platforms, such as Microsoft Hyper-V, Linux KVM, or Citrix Xen. Consider migrating to container platforms or cloud-native infrastructure services as part of a broader IT modernization strategy. This approach may offer greater flexibility and cost savings in the long term. ![](/static/wheel-icon-gold-pink.svg) ### 4. Plan for Transition and Future Proofing Develop a robust transition plan for moving from perpetual licensing to subscription models, aligning this transition with the end-of-life cycle of server and storage hardware. Evaluate the potential impact of Broadcom’s changes on your ability to deliver scalable, resilient, and cost-effective business services. ![](/static/consistency-icon-gold-pink.svg) ### 5. Leverage Community and Industry Forums Participate in industry forums and user groups, such as the VMware User Group (VMUG), to share experiences and strategies with peers. This collective approach can provide valuable insights and potentially increase leverage in negotiations with Broadcom. ## Takeaways To successfully navigate the changes following Broadcom’s acquisition of VMware, CIOs must take a proactive approach to managing their IT strategies. By assessing current dependencies, exploring alternative technologies, and optimizing existing infrastructure, organizations can mitigate potential disruptions. Furthermore, staying informed about market trends and emerging technologies that may offer viable alternatives to VMware is crucial. Regularly reviewing your strategic planning assumptions will help ensure they remain aligned with evolving industry dynamics, enabling your organization to adapt to new challenges and opportunities effectively. ## Why Kubermatic? Kubermatic will help you develop the right VMware exit strategy and explore your Kubernetes-Native Virtualization. Streamline your infrastructure and unleash the full potential of Kubernetes for your organization’s cloud needs with **Kubermatic Virtualization** — the next evolution in cloud infrastructure. Kubermatic Virtualization allows you to seamlessly build your private cloud entirely with Kubernetes. Our advanced infrastructure design and Kubernetes expertise ensure efficient cloud adoption and scalable management. - Establish a private cloud native infrastructure entirely using Kubernetes, eliminating the need to run multiple stacks. - Utilize Kubernetes API as the foundation for all services and operations. - Achieve cost efficiency through streamlined Kubernetes-based management and scalability. ## Future-Proof Your Infrastructure Building your private cloud entirely on Kubernetes addresses VMware migration challenges by offering: ![](/static/gear-icon-pink-grad.svg) ### 100% Control Over your infrastructure allows for customized optimizations and integrations tailored to your specific needs. ![](/static/transformation-icon-gold-pink.svg) ### Flexibility Kubernetes enables you to design a cloud infrastructure that is adaptable and scalable, reducing dependency on proprietary solutions. ![](/static/cash-gold-pink.svg) ### 3x Cost Saving Open source components can lower licensing fees and avoid vendor lock-in, leading to significant cost savings. ![](/static/cloud-icon-gold-pink.svg) ### Seamless Integration Kubernetes simplifies the migration of VM workloads to a containerized environment, easing the transition away from VMware's legacy systems. ## Get Started Today Partner with us to migrate to an open source cost-effective VMware alternative. Contact our team to develop the right VMware exit strategy for your organization. [Contact Sales](/contact-sales/) [Request a Demo](/demo/) ## Other Resources [Download the Full PDF](/static/Strategic-Paths-for-CIOs-After-Broadcoms-VMware-Acquisition.pdf?v=2) [Resource Page](/resources/steering-the-roadblocks-strategic-paths-for-cios-after-broadcoms-vmware-acquisition/) [VMware Alternative](/info/vmware-alternative/) --- ## Steering the Roadblocks: Strategic Paths for CIOs After Broadcom's VMware Acquisition - **URL:** https://www.kubermatic.com/resources/steering-the-roadblocks-strategic-paths-for-cios-after-broadcoms-vmware-acquisition/ - **Date:** 2026-01-06 - **Description:** Get actionable insights for managing IT infrastructure, ensuring business continuity, and leveraging emerging technologies. Solution Brief includes a roadmap for CIOs to assess current dependencies, explore alternative technologies, and optimize existing infrastructure. # Steering the Roadblocks: Strategic Paths for CIOs After Broadcom’s VMware Acquisition ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Solution Briefs In the wake of Broadcom’s acquisition of VMware, CIOs must proactively reassess their IT strategies. This involves evaluating current dependencies, exploring alternative technologies, and optimizing infrastructure to avoid disruptions. Embrace cloud-native containerization to modernize legacy systems, seamlessly transitioning VM workloads to Kubernetes environments. Download our free Solution Brief: - Uncover the Key Impacts of Broadcom’s VMware Acquisition - Follow 5 Strategic Steps to Navigate Your VMware Migration - Explore Kubernetes-Native Virtualization Solutions with Kubermatic [Download](/static/Strategic-Paths-for-CIOs-After-Broadcoms-VMware-Acquisition.pdf?v=2) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## KKP 2.26: Optimized Bare Metal Kubernetes and Advanced Management for Cutting-Edge Deployments - **URL:** https://www.kubermatic.com/blog/kkp-2.26-optimized-bare-metal-kubernetes-and-advanced-management-for-cutting-edge-deployments/ - **Date:** 2026-04-30 - **Description:** Discover Kubermatic Kubernetes Platform (KKP) 2.26 featuring Tinkerbell integration for seamless bare metal provisioning, support for Kubernetes 1.30 and 1.31 and more. - **Categories:** Products - **Tags:** KKP - **Authors:** Csenger Szabo We're pleased to unveil the latest version of **Kubermatic Kubernetes Platform (KKP) 2.26**! Packed with groundbreaking additions such as Tinkerbell integration for seamless bare metal provisioning, support for Kubernetes 1.30 and 1.31, enhanced automation capabilities, and advanced tools to streamline cluster operations, this release takes Kubernetes lifecycle management to the next level. Whether you're running in the cloud or on-premise, KKP 2.26 offers unparalleled flexibility and control to elevate your infrastructure! ## Bare Metal Provider Support with Tinkerbell Integration The integration of the Tinkerbell bare metal provisioning stack into KKP 2.26 is a game-changer for organizations running Kubernetes on physical infrastructure. By leveraging Tinkerbell, users can now easily manage and provision bare metal clusters, unlocking new levels of flexibility and scalability. This feature extends KKP's reach to on-premise environments while maintaining the ease of Kubernetes lifecycle management that KKP users expect. With full support for Tinkerbell, administrators gain the ability to provision and manage Kubernetes clusters on physical servers just as seamlessly as they would on cloud infrastructure. ## Support for Kubernetes 1.30 and 1.31 With the addition of Kubernetes versions 1.30 and 1.31, KKP 2.26 ensures users can stay up to date with the latest improvements in Kubernetes technology. These versions include crucial updates related to performance, stability, and security, along with new features that streamline workload management and extend capabilities for enterprise-grade deployments. The seamless upgrade path offered by KKP guarantees that clusters can adopt these new versions without disrupting existing workflows, making it easier for operators to maintain a cutting-edge infrastructure. ## Default Applications Management KKP 2.26 introduces the capability to define and manage default applications across all newly created clusters. This new feature allows administrators to automatically install a set of preconfigured applications, ensuring that every new cluster has a standardized baseline of tools and services. Whether it's monitoring, security, or logging applications, this automation removes manual intervention and ensures that the necessary components are always in place, reducing the time to get clusters fully operational. ## Customize Presets The ability to customize presets in KKP 2.26 offers a more flexible approach to configuring cluster defaults. Administrators can define tailored presets that align with specific organizational policies or operational needs. This feature enables greater consistency across cluster deployments while maintaining the freedom to adapt to varying project requirements or environmental constraints in KKP Projects. ## Static Labels for Clusters The new static labels feature in KKP 2.26 provides a method to assign fixed labels to clusters that remain immutable throughout their lifecycle. These labels are particularly useful for tagging clusters with information such as compliance requirements, environment roles, or operational categories. By enforcing static labels, KKP enhances cluster organization and makes it easier to apply consistent management policies across a multi-cluster environment, especially in large-scale infrastructures. ## Audit Logging Webhook Backend The introduction of an audit logging webhook backend in KKP 2.26 elevates security and compliance efforts by enabling detailed logging of user and system actions within the platform. This feature allows administrators to route audit logs to external systems for real-time monitoring, analysis, and archival. The addition of webhook support ensures that KKP can integrate with a wide array of third-party logging systems, making it easier to track activity and meet regulatory or security requirements across Kubernetes clusters. ## Other Valuable Features ### Update KubeLB Integration to Support New Features in 1.1 The integration with [KubeLB](/products/kubelb/) has been updated to support new features available in version 1.1, allowing for more advanced load balancing configurations within Kubernetes clusters. These enhancements improve network performance and provide administrators with more options to fine-tune their load balancing setups, leading to more efficient traffic management in large-scale deployments. ### Enable/Disable ETCD Backups in Admin Settings In KKP 2.26, administrators now have the flexibility to enable or disable ETCD backups directly from the admin settings. This feature provides greater control over backup schedules and simplifies the management of backup operations reducing confusion in User Cluster owners. By allowing backups to be toggled on or off as needed, this feature ensures that resources can be optimized without compromising data safety or recovery strategies. ### Migration from Machine-Controller Userdata to OSM KKP 2.26 supports the migration from machine-controller userdata to the Operating System Manager (OSM). This transition improves the management of OS-level configurations and brings greater flexibility in handling updates and changes to machine provisioning. OSM provides a more centralized and efficient approach to managing node configurations, resulting in smoother operations and enhanced system performance. ### Custom Annotations for User Clusters This release introduces custom annotations for user clusters, giving administrators more granularity in tagging and categorizing their resources. Custom annotations can be applied during cluster creation and serve a variety of purposes, from integration with external systems to tracking compliance or cost allocation. This feature enhances the ability to organize and manage clusters in large environments. ### Support for Enabling Cloud Drive on OpenStack VMs KKP 2.26 expands OpenStack support by allowing cloud drives to be enabled on OpenStack VMs. This addition improves the storage options available for Kubernetes clusters running on OpenStack, making it easier to manage storage resources dynamically. The feature helps ensure that cloud-native workloads can fully leverage the scalability and flexibility of OpenStack's storage architecture. ### Automate Addon Maintenance Maintaining and updating cluster add-ons can be time-consuming, but KKP 2.26 introduces automation for add-on maintenance. This feature ensures that add-ons are regularly updated without requiring manual intervention, reducing the risk of outdated software and improving security. By automating add-on maintenance, administrators can ensure that clusters are always running the latest and most secure versions of essential tools and services. ### Add Single Namespace Mode for KubeVirt Provider KKP 2.26 introduces a single namespace mode for the KubeVirt provider, streamlining the management of virtual machines (VMs) by reducing complexity in multi-namespace environments. This feature enables administrators to manage VM workloads within a single namespace, making it easier to maintain and monitor VMs without needing to juggle multiple namespaces across the cluster. ### Supporting VM Groups in vSphere KKP 2.26 brings enhanced support for managing VM groups within vSphere. This feature allows users to more efficiently group and manage virtual machines, particularly in larger, more complex environments. By adding this capability, KKP makes it easier to organize and allocate resources, leading to smoother operations for clusters running on vSphere. ### CoreDNS Resource Overrides With KKP 2.26, administrators can now configure resource overrides for CoreDNS, giving them more control over the resource allocation of this critical DNS service. By customizing the resource settings, users can optimize CoreDNS performance to meet the demands of larger or more resource-intensive clusters. ### Allow eBPF Proxy Mode When CNI is None In this release, KKP adds support for eBPF proxy mode when no Container Network Interface (CNI) is configured. This enhancement gives users more options for handling network traffic efficiently in specific cluster setups where CNI is not needed or desired. ### Add Gzip Support for ETCD Snapshots The introduction of Gzip compression for ETCD snapshots reduces storage requirements and speeds up the backup process. This feature is particularly useful in environments with high data volumes, ensuring that backups are performed more efficiently and with less impact on overall system performance. ### Support for Configuring API Server Service Type KKP 2.26 allows for greater customization of the API server by enabling users to configure its service type. This gives administrators more control over how the API server is exposed and accessed, particularly in environments with specific networking or security requirements. ### Rework KKP Helm Charts to Use Upstream Charts As part of ongoing efforts to align with upstream Kubernetes standards, KKP 2.26 includes a significant rework of its Helm charts. This ensures better compatibility with the broader Kubernetes ecosystem and simplifies the deployment and management of KKP components. ### Enable Editing Allowed IP Ranges for NodePorts KKP 2.26 introduces a feature that allows administrators to edit the allowed IP ranges for NodePorts. This adds an extra layer of security by enabling tighter control over which IP addresses can access NodePort services, improving security in environments where exposure to public networks needs to be minimized. ### Make Additional OpenStack LoadBalancer Cloud-Config Parameters Configurable Per Datacenter In this release, KKP adds the ability to configure additional cloud-config parameters for OpenStack LoadBalancers on a per-datacenter basis. This feature allows for more granular control over load balancer settings in multi-datacenter environments, ensuring that configurations can be tailored to the specific needs of each location. ### Add the Option to Hide OS from Admin Settings This feature allows administrators to hide certain operating system (OS) options from the admin settings interface. By limiting the visible OS options, administrators can streamline the deployment process, ensuring that only the approved OS configurations are used across the organization. This is particularly beneficial in environments with strict compliance requirements or where specific OS standards must be enforced. ### Add Insecure/HTTP Flags to Helm Sources in AppDefinitions In KKP 2.26, administrators can now add insecure/HTTP flags to Helm sources within AppDefinitions. This feature facilitates the use of non-HTTPS sources when configuring applications in Kubernetes clusters, which is especially useful in development or testing environments. By enabling this option, users can bypass secure connections where they are not necessary, speeding up development cycles. --- ## Bridging IT/OT in Manufacturing: Scaling, Security, and the Future of Industrial Technology - **URL:** https://www.kubermatic.com/resources/bridging-it-ot-in-manufacturing-scaling-security-and-the-future-of-industrial-technology/ - **Date:** 2024-10-11 - **Description:** In this panel discussion, experts will discuss how new technologies, like containers and AI at the edge, are reshaping the landscape, and what this means for the future of industrial operations. # Bridging IT/OT in Manufacturing: Scaling, Security, and the Future of Industrial Technology ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch the panel discussion with Tobias Schneck, Johannes Mundorf and Alfred Schmid at ContainerDay Manufacturing 2024 This panel discussion will explore the evolving intersection of IT and OT in the manufacturing industry, focusing on the challenges and opportunities in scaling, security, and infrastructure. Experts will discuss how new technologies, like containers and AI at the edge, are reshaping the landscape, and what this means for the future of industrial operations. We’ll also delve into the organizational and technical barriers that must be overcome to fully realize the benefits of these advancements over the next 3 to 5 years. **Speakers: Tobias Schneck, Principal Architect at Kubermatic with Johannes Mundorf (SmartFactory Kaiserslautern / DFKI Kaiserslautern) and Alfred Schmid (Steadforce)** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Kubermatic Virtualization - **URL:** https://www.kubermatic.com/products/kubermatic-virtualization/ - **Date:** 2026-05-20 - **Description:** Seamlessly build your private cloud entirely with Kubernetes. Welcome to the next evolution in cloud infrastructure! # Kubermatic Virtualization Modernize your infrastructure by building your private cloud entirely with Kubernetes. Welcome to the next evolution in cloud infrastructure! [Get your free demo](/contact-sales/) [VMware Migration](/info/vmware-alternative/) [Documentation](https://docs.kubermatic.com/kubermatic-virtualization/latest/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) **Run legacy VMs, modern containers, and high-performance AI/GPU workloads on one Kubernetes-native platform.** **Say goodbye to unpredictable licensing. Choose open, Kubernetes-native virtualization.** ## Save Your Budget & Maintain High Reliability ### Legacy infrastructure - Running multiple stacks - Addressing Outdated Components in Legacy Private Clouds - Exhaustive Price Hikes - Rigid Infrastructure ### Kubermatic Virtualization - Build a private cloud entirely with Kubernetes - Reduce dependency on proprietary solutions - Simplify the migration of existing VMs from diverse environments to a unified platform - Harvest the Innovation and Support of the Open-Source Community ## Get 100% Control Over Your Infrastructure #### Your Private Cloud Built Completely on K8s Tired of juggling multiple stacks? With the [KubeVirt](/products/kubermatic-kubernetes-platform/edge/#kubevirt) integrated into the product, **Kubermatic Virtualization** offers a unified solution, providing a common environment for both Kubernetes and virtualized workloads. With seamless networking capabilities to manage traffic across complex environments and scalable storage solutions to handle dynamic workloads, say goodbye to the headache of managing disparate systems and hello to streamlined operations. Integrate Kyverno to automatically enforce security and compliance policies, ensuring governance across all Kubernetes clusters and workloads within your private cloud. ## For Business Continuity and Advanced Operations **Kubermatic Virtualization UI** is your command center for managing a modern, converged infrastructure. This centralized console is designed to be your single pane of glass, taming the complexity of running both virtual machines (VMs) and containers on a unified Kubernetes-native platform. It abstracts the power of KubeVirt, KubeOVN, and KubeOne into one intuitive interface, making it easy for any administrator to manage a production-ready private cloud. It looks like the demo preview couldn't load. This is often caused by ad blockers, cookie settings, or disabled JavaScript. Don't worry, though—you can still play! Just click below to launch the demo in a new tab. [Play in new tab](https://app.arcade.software/share/p7p6o4nfc2OJgNRgafjZ) > Our collaboration with Kubermatic enabled us to leverage professional support for key components, including KubeVirt and Kube-OVN, ultimately maturing our production platform and solidifying its readiness for enterprise-grade deployments. Dietrich Christian, Product Manager for Cloud, Swisscom [Read the Customer Success Story](/customers/swisscoms-journey-from-vendor-lock-in-to-cloud-native-infrastructure-platform/) ## Key Features ![](/static/cycle-grad-icon.svg) ### High Availability (HA) The underlying Kubernetes platform automatically restarts failed VM or container workloads on a healthy host, significantly reducing downtime ![](/static/exchange-icon.svg) ### Live VM Migration Move running virtual machines between physical hosts with zero downtime or interruption to users, enabling seamless hardware maintenance ![](/images/icons/visuals/item4.svg) ### Data Protection Ready Integrates easily with third-party backup and recovery solutions via Kubernetes-native APIs and hooks ![](/static/centralized-grad-icon.svg) ### Unified VM & Container Platform Run and manage virtual machines and containers side-by-side ![](/static/icons/slash-in-brackets-icon.svg) ### Kubernetes-Native Management API Use a single, unified control plane for all infrastructure ![](/images/icons/transformation.svg) ### Integrated Cloud-Native Networking (KubeOVN) A flat, high-performance L2/L3 network for all workloads ![](/static/gear-icon.svg) ### Automated Bare-Metal Cluster Provisioning (KubeOne) Simplify the deployment and lifecycle of the foundational platform ![](/static/struct-grad-icon.svg) ### Centralized Management Console A single pane of glass for all operations ![](/static/icons/kubernetes-icon.svg) ### Provision Tenant Kubernetes Clusters Empower teams with a VM-based Kubernetes cluster (KubeOne) ![](/images/icons/visuals/item16.svg) ### Zero Trust Policy No user, device, or workload, regardless of location (internal or external), is inherently trusted and must be continuously authenticated and authorized before being granted access to specific tenant resources or services ![](/images/icons/graph-chart.svg) ### Introducing the enterprise-level installer - ### Fast Environment Bootstrap Your entire virtualization environment (Kubernetes, networking, and virtualization layer) is ready to use in minutes - ### Preconfigured Storage and Load Balancing The installer automatically includes default storage and load balancing options. No manual configuration needed - ### Simple Network Configuration Easily define your network settings during installation - no complex setup or manual steps required ## Steering the Roadblocks: Strategic Paths for CIOs After Broadcom's VMware Acquisition [![Labyrinth puzzle maze](/static/labyrinth-puzzle-maze_hu_c5a9f0a96624ceb6.jpg)](/solution-brief-strategic-paths-for-cios-after-broadcoms-vmware-acquisition/) In the wake of Broadcom’s acquisition of VMware, CIOs must proactively reassess their IT strategies. This involves evaluating current dependencies, exploring alternative technologies, and optimizing infrastructure to avoid disruptions. Embrace cloud-native containerization to modernize legacy systems, seamlessly transitioning VM workloads to Kubernetes environments. [Check Solution Brief](/solution-brief-strategic-paths-for-cios-after-broadcoms-vmware-acquisition/) ## Power Your Cloud with a Strong Partner Ecosystem KubeV integrates high-performance networking with advanced storage solutions, ensuring seamless VM operations and robust data management. Kubermatic's partner ecosystem enhances your cloud-native infrastructure with seamlessly integrated services and solutions across key areas. - [Storage](#partner-ecosystem-0) - [Backup & Disaster Recovery](#partner-ecosystem-1) Infrastructure-agnostic components seamlessly integrate with any network and CSI-compatible storage, ensuring flexibility, high availability, and efficient data management for your cloud-native workloads. ![Everpure](/static/everpure.svg) ![Portworx by Everpure](/static/portworx-by-everpure.svg) ![NetApp](/static/netapp.svg) KubeV delivers enterprise-grade backup and disaster recovery for virtual machine workloads running in Kubernetes environments. Built for reliability and performance, KubeV ensures critical data can be quickly restored to minimize downtime and maintain service continuity during unplanned events. ![Portworx by Everpure](/static/portworx-by-everpure.svg) ![Trilio](/static/trilio.svg) ### Browse All Kubermatic Partners [Explore](/partners/) ## Why Kubermatic Virtualization? ![](/images/icons/admin-icon.svg) ### Built on Kubernetes Utilize Kubernetes API as the foundation for all services and operations. Kubernetes enables you to design a cloud infrastructure that is adaptable and scalable, reducing dependency on proprietary solutions. ![](/images/icons/transformation.svg) ### Cost-Efficient Cloud Solutions Transitioning from VMware's expensive licensing model to Kubermatic Virtualization (KubeV) offers substantial cost savings by leveraging an open-source framework. By using open-source components, KubeV reduces vendor lock-in, leading to greater flexibility and seamless integration with other products. ![](/static/gear-icon.svg) ### Designed to Upgrade Your Infrastructure Modernize legacy systems through cloud-native containerization, seamlessly converting VM workloads into Kubernetes-based environments. Built on predominantly open-source components, KubeV provides you with greater customization and integration capabilities. [Contact Sales](/contact-sales/) --- ## Troubleshooting with AI - How k8sgpt makes debugging Kubernetes clusters easier - **URL:** https://www.kubermatic.com/blog/troubleshooting-with-ai-how-k8sgpt-makes-debugging-kubernetes-clusters-easier/ - **Date:** 2026-04-30 - **Description:** Discover how k8sgpt simplifies Kubernetes cluster troubleshooting with AI. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Mario Fahlandt About a year and a half ago, on March 28, 2023, one of the fastest-growing projects of the CNCF (Cloud Native Computing Foundation) became a reality. With k8sgpt, there is another practical use case for AI in the IT environment. The tool offers an efficient way to detect and resolve errors and issues in a Kubernetes cluster. Artificial intelligence is a hot topic that everyone is talking about, but practical applications are often limited. In a spur-of-the-moment action, a new open-source project emerged in the cloud-native world. Alex Jones and Thomas Schuetz saw the advantage of Large Language Models (LLMs) and their increasing prevalence. The idea behind it: using AI to debug Kubernetes clusters. In a cluster, problems are often not easy to identify, and error messages are not easy to understand. With k8sgpt, a solution for these specific challenges is now available. The tool analyzes these errors and sends the error message to an AI interface. Users receive a clear error description and guidance with possible steps to resolve the error in response. ## Two options for using k8sgpt There are two ways to use k8sgpt. One option is to integrate it directly into your own CLI. Linux, Windows, and OSX are supported platforms, and simple installation options can be found in the official documentation. By choosing this option, access to the cluster is granted via the existing kubeconfig. k8sgpt performs a pre-analysis of the data and then sends it to the AI backend. The result is an output in the shell that lists the various errors and provides possible solutions. The option to use different AIs underscores the independence that the tool strives to achieve. All major commercial providers are covered. There are backends for OpenAI, Gemini, Azure OpenAI, AWS SageMaker, and Bedrock, as well as the option to use local LLMs via localAI and Ollama. This is especially interesting since many companies in the DACH region do not allow the use of commercial providers. ## Data privacy takes precedence k8sgpt is transparent about the data it processes and sends to the AI. Depending on the analyzer used, k8sgpt collects different data. An example would be `k8sgpt analyze pod`. The following data is collected: Container Status Message, Pod Name, Pod Namespace, and Event Message. Only when k8sgpt is used with the - explain flag, data is sent to the AI backend. The data sent in this case are the same data collected by k8sgpt itself. By using the anonymize flag, data can be anonymized before being sent to the AI backend. Anonymization includes Deployment Name and Deployment Namespace. No logs are collected, and the API server only collects basic data needed by the k8sgpt analyzer. The safest way is, of course, to use a local LLM variant. There are many options available. The easiest way is to run a local LLM in your cluster directly, and the most convenient way to do this is with LocalAI or Ollama, as these solutions can be easily installed in Kubernetes clusters. ## Automation with the k8sGPT Operator The k8sGPT Operator offers a convenient way to use k8sgpt within a Kubernetes cluster and fully utilise the advantages of AI-supported troubleshooting. It automates the execution of scans of multiple clusters at regular intervals. These scans then collect the data from the clusters and forward it to Prometheus so that the status of multiple clusters can be viewed centrally. Of course, this can also be automated and implemented in line with the Infrastructure as Code model. The operator can be installed via ArgoCD, for example. Helm, which is a package manager for Kubernetes, is used for the installation itself. After installation, the operator must be configured with a k8sgpt resource. This resource defines the settings for the scans, such as the namespace to be analysed, the AI backend to be used and the type of data to be collected. The operator offers various options for customisation. For example, users can configure the frequency of scans, the filters to be used and the behaviour during data collection. **Conclusion**: The wide range of functions and options described make k8sgpt an extremely useful tool for debugging Kubernetes clusters. --- ## Kubernetes Podcast: KCP - The Future of Kubernetes and Multi-Tenancy - **URL:** https://www.kubermatic.com/resources/kubernetes-podcast-kcp-the-future-of-kubernetes-and-multi-tenancy/ - **Date:** 2024-12-05 - **Description:** Learn all about KCP, logical clusters and API exports in this Kubernetes Podcast Episode, featuring Marvin Beckers # Kubernetes Podcast: KCP - The Future of Kubernetes and Multi-Tenancy ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ![](/static/kubernetes-podcast-image-of-marvin-beckers_hu_80b416fc709e423c.png) Podcast ## Discover KCP: Marvin Beckers' Vision for Kubernetes In this episode of the Kubernetes Podcast from Google, hosts Abdelseguiwar and Kazlan Fields welcome Marvin Beckers, team lead at Kubernetes and a key contributor to the CNCF Sandbox Project KCP. During this episode, you will hear all about multi-tenant solutions, cluster management utilities, and the advantages of KCP over traditional Kubernetes setups. Marvin explains the concepts of logical clusters, API exports, and multi-tenancy architecture, discussing how you could use KCP to optimize the Kubernetes resource model beyond just container orchestration. **This podcast covers**: - KCP’s role in Kubernetes management - Benefits of multi-tenant architecture in KCP - Enhancing platform engineering with KCP - The significance of KCP in hybrid cloud applications [Listen](https://kubernetespodcast.com/episode/238-kcp/) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Transforming Legacy Systems: How Kubermatic Virtualization Enabled Cost-Effective Private Cloud Solutions for a Telecommunications Leader - **URL:** https://www.kubermatic.com/customers/telecommunications/ - **Date:** 2026-06-23 - **Description:** Discover how Kubermatic Virtualization transformed a legacy VMware-based infrastructure into a cost-effective, flexible private cloud solution for a telecommunications leader. # Transforming Legacy Systems: How Kubermatic Virtualization Enabled Cost-Effective Private Cloud Solutions for a Telecommunications Leader ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## The Challenge ### Bridging the Gap Between Cloud Native Containerization and Legacy VM Infrastructure Our telecommunications client faced a significant challenge as they sought alternatives to VMware due to concerns over increased costs following VMware’s acquisition by Broadcom. Their existing infrastructure was heavily optimized for VMware, with specific networking, storage, and architectural setups tailored to the platform. The main challenge was migrating from this legacy VMware-based infrastructure to a modern containerization platform using [KubeVirt](/products/kubermatic-kubernetes-platform/edge/#kubevirt) which sits at the heart of the **Kubermatic Virtualization (KubeV)**, without disrupting established processes and infrastructure. A key part of the challenge was shifting from the VMware mentality — where infrastructure is tightly coupled and stateful—to a containerization platform where everything is stateless and orchestrated. The transition posed several hurdles, including differences in networking, storage models, and overall architecture between traditional virtualized environments and cloud-native containerization. Additionally, KubeVirt, originally designed to run legacy workloads alongside containers, was not intended as a direct replacement for VMware. Therefore finding a “sweet spot” where KubeVirt could mimic the existing VMware environment without requiring a complete overhaul of the client’s infrastructure was critical to overcoming these challenges. ## The Solution ### Creating a Multi-Tenant Platform with KVM and KKP for Seamless Integration of VMs and Containerized Workloads The solution was the development of a platform that enabled our telecommunications client to run KVM-based virtual machines, similar to VMware’s vSphere or Cloud Director. This platform supported multi-tenancy, allowing different VMs to operate in dedicated VPCs, subnets, and storage environments. A special network fabric and CNIs were implemented to enable this level of isolation between tenants, allowing VMs from different tenants to run on the same infrastructure securely. Additionally, the Kubermatic Kubernetes Platform (KKP) was used to orchestrate the compute power, making the platform highly efficient for managing both VMs and containerized workloads. This platform bridged the gap between legacy VMs and modern cloud-native infrastructure. ## The Impact ### Cost Efficiency and Greater Control with a Flexible, Open-Source Private Cloud Solution The primary impact of implementing Kubermatic Virtualization (KubeV) for our client was significant cost efficiency and enhanced control over their infrastructure. By moving away from VMware’s expensive, all-inclusive licensing model — driven up by Broadcom’s acquisition — the client was able to adopt a more flexible and cost-effective solution. KubeV, built on predominantly open-source components, provided our telecommunications customer with greater customization and integration capabilities, reducing vendor lock-in and allowing seamless integration with other products. This shift not only improved their operational efficiency but also offered better control and adaptability in managing their private cloud infrastructure. ![Mountain peaks covered in snow background](/static/mountain-peaks-covered-in-snow-bg.jpg) ## Telecommunications Faced with the need to modernize its legacy infrastructure, the client sought to transition from traditional VMware-based systems to a more flexible, cloud-native platform. With a strong focus on innovation and efficiency, the company aimed to reduce costs while maintaining its high standards of service, driving the need for a scalable and open-source private cloud solution. This shift was critical to supporting their diverse operational needs, from managing customer data to enabling new digital services in a competitive telecommunications landscape. --- ## Fireside Chat with Kelsey Hightower & Sebastian Scheele - **URL:** https://www.kubermatic.com/resources/fireside-chat-with-kelsey-hightower-and-sebastian-scheele/ - **Date:** 2024-10-14 - **Description:** As we celebrate the 10th anniversary of Kubernetes, don't miss this fireside chat to learn more about the insights into the evolution of Kubernetes, its impact on the tech industry, and the future directions it might take! # Fireside Chat with Kelsey Hightower & Sebastian Scheele ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch the fireside chat with Kelsey Hightower & Sebastian Scheele at ContainerDays Conference 2024 Join us for an engaging fireside chat as we celebrate the 10th anniversary of Kubernetes, featuring Kelsey Hightower and Sebastian Scheele. Don’t miss insights into the evolution of Kubernetes, its impact on the tech industry, and the future directions it might take! **Speakers: Sebastian Scheele, Co-Founder & CEO at Kubermatic with Kelsey Hightower** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Sandbox to confidential containers: A brief on the evolution of container isolation - **URL:** https://www.kubermatic.com/resources/sandbox-to-confidential-containers-a-brief-on-the-evolution-of-container-isolation/ - **Date:** 2024-10-14 - **Description:** Watch this talk to discover more about the evolution of container isolation from sandboxing to confidential containers, the use cases & concerns that confidential container addresses & how it differs from sandboxing. # Sandbox to confidential containers: A brief on the evolution of container isolation ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Akash Gautam's talk at ContainerDays Conference 2024 By default, the containers run as processes sharing the host’s kernel. This results in a potential security threat where all the containers on a host get compromised. Even if any one of the containers gets compromised, container sandboxing mitigates this threat by running each container inside a lightweight VM & thus creating an isolation layer between containers as well as between containers & the host kernel. However, this doesn’t guarantee protection when the host itself is compromised, which leads us to confidential containers where containers get isolated at the hardware level providing protection from unauthorized access from the host, infra providers & other entities with privileged access & thus ensuring the integrity of the data & code even while they are in use. In this talk, I will discuss the evolution of container isolation from sandboxing to confidential containers, the use cases & concerns that confidential container addresses & how it differs from sandboxing. **Speaker: Akash Gautam, consultant at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Container Days 2024: Building a Platform Engineering API Layer with kcp - **URL:** https://www.kubermatic.com/resources/building-a-platform-engineering-api-layer-with-kcp-cds24/ - **Date:** 2024-10-16 - **Description:** kcp expands the world of platform engineering beyond the limits of single Kubernetes clusters, and therefore transforms the scale at which platform teams and internal service providers can operate. Have a look at this talk to explore patterns for both service providers and developers and how kcp makes their lives easier. # Building a Platform Engineering API Layer with kcp - CDS 2024 ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Marvin Beckers' talk at ContainerDays Conference 2024 Self-service is a central aspect of platform engineering, and platform engineering teams frequently build on top of Kubernetes to utilise its amazing API design. The kcp project has been accepted into the CNCF Sandbox in 2023 and extends Kubernetes API concepts beyond container orchestration. This talk will discuss how kcp supercharges platform engineering with a global control plane for all internal services. As a central API layer, kcp enables a SaaS-like experience between internal service providers and developers, transforming internal developer platforms into a service marketplace. All via concepts and tools that developers working with Kubernetes already know and love. kcp expands the world of platform engineering beyond the limits of single Kubernetes clusters, and therefore transforms the scale at which platform teams and internal service providers can operate. This talk will explore patterns for both service providers and developers and how kcp makes their lives easier. **Speaker: Marvin Beckers, Team Lead at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Fast & Secure: Package, Sign, Verify, and Deploy - **URL:** https://www.kubermatic.com/resources/fast-secure-package-sign-verify-and-deploy/ - **Date:** 2024-10-14 - **Description:** This session delves into the intersection of supply chain security and platform engineering by exploring GitOps, Sigstore, and OCI artifacts and registries. You will learn how easy it is to store helm releases in an OCI registry, secure them with Cosign, and verify the signature with Flux with a well-designed demo. # Fast & Secure: Package, Sign, Verify, and Deploy ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Koray Oksay's talk at ContainerDays Conference 2024 Supply chain security is crucial for the platform engineering teams. In addition to security concerns, they need to provide seamless and efficient tools for their clients. This session delves into the intersection of supply chain security and platform engineering by exploring GitOps, Sigstore, and OCI artifacts and registries. Attendees will learn how easy it is to store helm releases in an OCI registry, secure them with Cosign, and verify the signature with Flux with a well-designed demo. Helm supports OCI registries since version 3.8.0. Flux can verify packages signed with Cosign. We will demonstrate using all these features with the Zot registry and showcase supply chain security. **Speakers: Koray Oksay, Kubernetes Consultant at Kubermatic with Batuhan Apaydin (Trendyol)** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Elephant in the room - **URL:** https://www.kubermatic.com/resources/elephant-in-the-room/ - **Date:** 2024-10-14 - **Description:** The virtualization landscape is undergoing a significant shift. Modernization of applications via containerization with platforms like Kubernetes is one driver, but the current shift is dominated by the question: What platform should I be using for virtualization in future? Learn more about this in this talk! # Elephant in the room ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Sebastian Scheele's talk at ContainerDays Conference 2024 The virtualization landscape is undergoing a significant shift. Modernization of applications via containerization with platforms like Kubernetes is one driver, but the current shift is dominated by the question: What platform should I be using for virtualization in future? Kubernetes is one of the prospects which can run containers and virtual machines alike. Kubernetes floats on a rich ecosystem of open-source projects and commercial products. Both sides are now exposed to the increased enterprise requirements around virtualization workloads, and find themselves at the epicentre of change and are forced to adapt and innovate. This presentation looks at Kubernetes - an enterprise-ready and open platform - for virtualization, how vendors are catching up, what this means for your personal timelines, and how patience and a crawl-walk-run strategy are your allies in defining this future platform. How you can give your teams sufficient lead time to become successful in building, and owning your next-generation virtualization platform. **Speakers: Sebastian Scheele, Co-Founder & CEO at Kubermatic with Fabian Deutsch (RedHat)** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## FOCUS ON: DEVOPS Podcast on KCP with Marvin Beckers - **URL:** https://www.kubermatic.com/resources/focus-on-devops-podcast-on-kcp-with-marvin-beckers/ - **Date:** 2024-10-03 - **Description:** Discover the power of Kubernetes APIs in our latest podcast featuring Marvin Beckers at ContainerDays 2024 in Hamburg. # FOCUS ON: DEVOPS Podcast on KCP with Marvin Beckers ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ![](/static/podcast-on-kcp-with-marvin-beckers_hu_96440dffcdb276ae.jpg) Podcast ## FOCUS ON: DEVOPS Podcast on KCP with Marvin Beckers Lots of great and interesting people, exciting talks, and inspiring conversations in a unique atmosphere in Hamburg at Kampnagel during ContainerDays Conference 2024. Marvin Beckers explains what the CNCF project KCP is all about and the amazing possibilities it offers for managing clusters, services, and workloads using Kubernetes APIs. He will also discuss the KCP-based offering from Kubermatic, the Kubermatic Developer Platform (KDP), and the added value it can provide to developers and application owners through a kind of self-service. [Listen](https://focusondevops.podigee.io/109-container-days-2024-kcp) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## KCD's Munich 2024: Cloud Native Security: A New Paradigm for a New World - **URL:** https://www.kubermatic.com/resources/cloud-native-security-a-new-paradigm-for-a-new-world-munich/ - **Date:** 2024-10-16 - **Description:** Discover a new security paradigm in the cloud native world in this talk at KCD's Munich 2024. It will introduce the concepts of zero-trust security, shift-left security, and continuous security, and explain how these concepts can be applied to cloud native environments! # Cloud Native Security: A New Paradigm for a New World - KCD’s Munich 2024 ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Mario Fahlandt's talk at KCD's Munich 2024 Cloud native computing has revolutionized the way applications are developed and deployed. However, it has also introduced new security challenges. The traditional security paradigm, which is based on perimeter-based security, static security controls, and a reactive security posture, is no longer sufficient to protect cloud native environments. This talk will discuss the need for a new security paradigm in the cloud native world. It will introduce the concepts of zero-trust security, shift-left security, and continuous security, and explain how these concepts can be applied to cloud native environments. The talk will also discuss the benefits of the new security paradigm, such as improved security posture, reduced risk, and increased agility and scalability. Finally, the talk will provide some examples of organizations that have successfully implemented the new security paradigm, and discuss some emerging cloud native security technologies. **Speaker: Mario Fahlandt, Customer Delivery Architect at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## No More YAML Soup: Taking Control with Dagger's Pipeline-as-Code Philosophy - **URL:** https://www.kubermatic.com/resources/no-more-yaml-soup-taking-control-with-daggers-pipeline-as-code-philosophy/ - **Date:** 2024-08-29 - **Description:** Have a detailed walkthrough of transitioning from a YAML-based pipeline to a Dagger-based setup, illustrating the process with real-world examples and best practices in this session! # No More YAML Soup: Taking Control with Dagger’s Pipeline-as-Code Philosophy ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Koray Oksay's talk at KCD's Munich 2024 In today’s fast-paced software development landscape, maintaining complex, YAML-based CI/CD pipelines can become a bottleneck, leading to what many developers lament as “YAML Soup”. This talk proposes a revolutionary shift with the adoption of Dagger, developed by Solomon Hykes’s team, which replaces traditional, error-prone scripting with a robust, language-agnostic API and cross-language scripting engine. This session aims to demonstrate how Dagger enables developers to write their pipelines as code directly within the language of their project, thereby enhancing readability, maintainability, and scalability. We will start with an overview of Dagger, discussing its core concepts and advantages over traditional pipeline configurations. The presentation will include a detailed walkthrough of transitioning from a YAML-based pipeline to a Dagger-based setup, illustrating the process with real-world examples and best practices. Attendees will leave with a clear understanding of implementing Dagger in their projects, leading to more efficient and manageable development workflows. **Speaker: Koray Oksay, Kubernetes Consultant at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Announcing KubeLB v1.1: From Layer 7 Load Balancing to Advanced Enterprise Capabilities - **URL:** https://www.kubermatic.com/blog/announcing-kubelb-v1-1-from-layer-7-load-balancing-to-advanced-enterprise-capabilities/ - **Date:** 2026-04-30 - **Description:** KubeLB v1.1 is live. Dive into new features like Layer 7 Load Balancing, automated Tenant Registration, and the new SyncSecrets API for greater security. - **Categories:** Company - **Tags:** KubeLB, Announcements - **Authors:** Sebastian Scheele We are excited to announce the release of **KubeLB v1.1**! KubeLB has always been committed to providing a robust load balancing solution tailored for cloud-native environments. With v1.1, we've made substantial improvements that address user needs across different scenarios, from simple ingress management to complex, enterprise-level requirements. Whether you're using the Community Edition or the Enterprise Edition (See the [Feature Matrix](#feature-matrix)), there's something in this release to elevate your experience. So, fasten your seatbelts🚀 ## Exciting Upgrades for Community Edition (CE) Users ### Ingress and Layer 7 Load Balancing One of the most notable additions in this release is the support for Layer 7 load balancing. KubeLB now fully supports Ingress and Gateway API resources, allowing it to function as both an ingress controller and a gateway API controller. This enhancement means KubeLB can efficiently manage HTTPRoute, GRPCRoute, and other similar resources, providing granular control over traffic routing and application delivery. ### Automated Tenant Registration Managing tenants has never been easier. KubeLB v1.1 introduces automated tenant registration, replacing the older Namespace resource method with a more streamlined Tenant resource. This automation ensures that all necessary configurations, such as namespace creation and RBAC setup, are handled seamlessly, freeing up your time for more critical tasks. ### Gateway API v1 Support With this release, KubeLB now fully supports Gateway API v1, providing a standardized and flexible approach to managing traffic across distributed environments. This feature is particularly beneficial for users looking to leverage advanced routing capabilities within Kubernetes. ### Bring Your Own Secrets Security and flexibility are at the forefront of this release. The new SyncSecrets API allows users to synchronize secrets from tenant clusters to the load balancer cluster. This feature ensures that sensitive data is securely managed and accessible only where it’s needed. ## Powerful Enhancements for Enterprise Edition (EE) The Enterprise Edition of KubeLB builds on the foundation of the Community Edition, adding advanced features that cater to larger, more complex environments. ### Automated DNS Management KubeLB EE now includes automated DNS management, simplifying the process of domain management across tenants. Admins can configure allowed domains per tenant, and KubeLB will automatically handle the creation of DNS records, ensuring that all routing is correctly configured and maintained. ### TLS Termination and Certificate Management Security is paramount in any enterprise environment. With the introduction of automated certificate management, KubeLB EE ensures that all traffic is encrypted and secure. Admins can configure domain-specific certificate settings, and KubeLB will manage the issuance and renewal processes, minimizing the risk of expired certificates and ensuring uninterrupted service. ### Support for Multiple Gateways Unlike the Community Edition, where tenants are limited to a single gateway, the Enterprise Edition allows the configuration of multiple gateways per tenant. This feature provides greater flexibility and redundancy, ensuring that traffic can be routed efficiently even in complex network topologies. ### Limits for Gateways and Load Balancers Resource management is critical in large-scale environments. KubeLB EE now offers fine-grained control over the number of gateways and load balancers per tenant and across the entire management cluster. This ensures that resources are used efficiently and that no single tenant can monopolize system capacity. ### Support for Gateway API Alpha/Beta Features For those looking to experiment with the latest in traffic management technology, KubeLB EE includes support for alpha and beta features of the Gateway API, such as TLSRoute, TCPRoute, and UDPRoute. This allows early adopters to test and implement cutting-edge features in a controlled environment. <div id="feature-matrix" class="scrl-space"></div> <h2>Feature Matrix</h2> The KubeLB v1.1 Feature Matrix provides a comprehensive overview of the latest enhancements and capabilities in the new release. <div class="ft-table-holder -talign -dark-head"> <table> <thead> <tr> <th>Feature</th> <th>EE (Enterprise Edition)</th> <th>CE (Community Edition)</th> </tr> </thead> <tbody> <tr> <td><strong>Ingress</strong></td> <td><img src="/static/check-mark-icon.svg" alt="available" width="26" height="20"><span class="vis-hid">available</span></td> <td><img src="/static/check-mark-icon.svg" alt="available" width="26" height="20"><span class="vis-hid">available</span></td> </tr> <tr> <td><strong>Gateway API v1</strong></td> <td><img src="/static/check-mark-icon.svg" alt="available" width="26" height="20"><span class="vis-hid">available</span></td> <td><img src="/static/check-mark-icon.svg" alt="available" width="26" height="20"><span class="vis-hid">available</span></td> </tr> <tr> <td><strong>Bring your own secrets(certificates)</strong></td> <td><img src="/static/check-mark-icon.svg" alt="available" width="26" height="20"><span class="vis-hid">available</span></td> <td><img src="/static/check-mark-icon.svg" alt="available" width="26" height="20"><span class="vis-hid">available</span></td> </tr> <tr> <td><strong>Gateway API beta/alpha(TLS/TCP/UDP routes)</strong></td> <td><img src="/static/check-mark-icon.svg" alt="available" width="26" height="20"><span class="vis-hid">available</span></td> <td><img src="/static/cross-mark-icon.svg" alt="not available" width="20" height="20"><span class="vis-hid">not available</span></td> </tr> <tr> <td><strong>Multiple Gateways</strong></td> <td><img src="/static/check-mark-icon.svg" alt="available" width="26" height="20"><span class="vis-hid">available</span></td> <td><img src="/static/cross-mark-icon.svg" alt="not available" width="20" height="20"><span class="vis-hid">not available</span></td> </tr> <tr> <td><strong>DNS automation</strong></td> <td><img src="/static/check-mark-icon.svg" alt="available" width="26" height="20"><span class="vis-hid">available</span></td> <td><img src="/static/cross-mark-icon.svg" alt="not available" width="20" height="20"><span class="vis-hid">not available</span></td> </tr> <tr> <td><strong>Certificate Management</strong></td> <td><img src="/static/check-mark-icon.svg" alt="available" width="26" height="20"><span class="vis-hid">available</span></td> <td><img src="/static/cross-mark-icon.svg" alt="not available" width="20" height="20"><span class="vis-hid">not available</span></td> </tr> <tr> <td><strong>Limits for LoadBalancers, Gateways</strong></td> <td><img src="/static/check-mark-icon.svg" alt="available" width="26" height="20"><span class="vis-hid">available</span></td> <td><img src="/static/cross-mark-icon.svg" alt="not available" width="20" height="20"><span class="vis-hid">not available</span></td> </tr> </tbody> </table> </div> ## Conclusion KubeLB v1.1 is a significant milestone in our journey to provide the best load balancing solution for Kubernetes environments. With enhanced features like Layer 7 load balancing, automated tenant management, and advanced enterprise capabilities, this release is set to make your cloud-native operations more efficient, secure, and scalable. We encourage all users to upgrade to v1.1 and explore the new capabilities that KubeLB has to offer. For a detailed list of changes and to download the latest version, check out our [Release Notes](https://docs.kubermatic.com/kubelb/v1.1/release-notes/) and visit our [GitHub repository](https://github.com/kubermatic/kubelb)… and give us a star!;) Thank you for being part of the KubeLB community, and we look forward to your feedback and continued support as we advance in our mission to streamline and enhance Kubernetes load balancing. --- ## Transform Your Business Operations with IT Infrastructure Services - **URL:** https://www.kubermatic.com/blog/transform-your-business-operations-with-it-infrastructure-services/ - **Date:** 2026-04-30 - **Description:** Discover how IT infrastructure services can revolutionize your business operations. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Sebastian Scheele In order to maintain a competitive edge, today's businesses must be agile, efficient, and innovative. One of the key factors that can help achieve these goals is robust IT infrastructure. IT infrastructure services are more than just a backbone for your company's technology; they are the foundation for growth, innovation, and transformation. Let's explore how leveraging these services can revolutionize your business operations and set you on a path to success. ## What Are IT Infrastructure Services? IT infrastructure services encompass a broad range of essential technologies and processes that support the operation and management of your company's IT environment. These services typically include hardware (like servers and storage devices), software (such as operating systems and applications), networking components (like routers and switches), and data storage and management solutions. Additionally, IT infrastructure services cover maintenance, security, and support activities necessary to keep all systems running efficiently. Depending on the needs of the business, these services can be managed in-house, outsourced to a third-party provider, or a combination of both. ## Types of IT Infrastructure Services - **Hardware Management**: Involves the setup, maintenance, and repair of physical devices such as servers, desktops, laptops, and networking equipment. - **Software Management**: Includes the installation, configuration, and updating of operating systems and application software. - **Network Services**: Encompass the management of network connectivity, firewalls, routers, switches, and VPNs, ensuring secure and reliable communication across all business sites. - **Cloud Services**: Provide on-demand access to computing resources, storage, and applications through cloud providers, offering scalability and flexibility. - **Data Management and Storage**: Covers data backup, recovery, archiving, and storage solutions to ensure data integrity and availability. ## In-House vs. Managed IT Infrastructure Services When it comes to managing IT infrastructure, businesses have two primary options: in-house management or outsourcing to a managed service provider (MSP). **In-House IT Infrastructure Services** involve a company's own team handling all aspects of the IT environment. This approach provides complete control over systems, customization to specific needs, and immediate access to on-site resources. However, it often requires a significant investment in personnel, training, and equipment. The burden of managing and upgrading the infrastructure also falls entirely on the business, which can be both time-consuming and costly. **Managed IT Infrastructure Services**, on the other hand, allow businesses to outsource all or part of their IT management to a third-party provider. This option can reduce costs associated with hiring and maintaining an in-house IT team and provides access to a broader range of expertise and technologies. MSPs offer scalable solutions that can grow with the business, and they often provide around-the-clock support and proactive monitoring to prevent issues before they impact operations. The main trade-off is less direct control over the IT infrastructure, which some businesses may find challenging if they have highly specialized needs. Choosing between in-house and managed IT infrastructure services depends on your company's size, budget, and specific IT requirements. For many, a hybrid approach that combines the strengths of both options can offer the best of both worlds. By understanding and leveraging the right IT infrastructure services for your business, you can enhance operational efficiency, reduce costs, and position your company for future growth and success. ## Why Are Leaders Investing in IT infrastructure Consulting? IT infrastructure consulting helps leaders identify inefficiencies, implement best practices, and adopt new technologies that drive performance and cost savings. In a landscape where technology is constantly advancing, staying ahead with the right IT infrastructure is crucial, which is why more leaders are turning to consultants to guide their strategies and investments. This is where Kubermatic's spinoff project, [Cloud Native Labs](https://www.cloud-native.com/) comes in, offering comprehensive infrastructure [consulting services](https://www.cloud-native.com/consulting/) tailored to your cloud-native workloads. Our team at Cloud Native Labs collaborates closely with businesses to understand their specific needs, whether the goal is to modernize storage infrastructure, optimize network performance, or take advantage of bare metal servers. With our expertise, we help organizations achieve these objectives, ensuring their IT infrastructure is not only modernized but also cost-efficient, minimizing unplanned downtime and accelerating time-to-market. [Cloud Native Labs](https://www.cloud-native.com/) consulting services cover a range of projects, including edge rollouts, KubeVirt, OpenStack, Nutanix HCI, VMware vCloud & vSphere, bare metal Kubernetes, and GPGPU. By focusing on performance, reliability, and scalability, Cloud Native Labs ensures you have everything you need to stay ahead of your competition. As technology continues to advance, staying ahead with the right IT infrastructure is crucial. That's why more leaders are investing in IT infrastructure consulting, looking to experts like Cloud Native Labs to guide their strategies and investments. Whether you're planning a major infrastructure overhaul or looking to fine-tune your current setup, Cloud Native Labs services are designed to help you thrive in a fast-paced digital landscape. --- ## Revolutionizing Software Development: A Brief Look at the History and Future of Container Platforms - **URL:** https://www.kubermatic.com/blog/revolutionizing-software-development-a-brief-look-at-the-history-and-future-of-container-platforms/ - **Date:** 2026-04-30 - **Description:** Explore the evolution of container platforms from early virtualization and FreeBSD jails to modern orchestration tools like Kubernetes. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Julian Hansert Container platforms, also known as container orchestration systems, have become increasingly popular in recent years, revolutionizing the way software is developed, tested, and deployed. But where did container platforms come from? How did they evolve into the powerful tools we know today? In this blog post, we will take a trip down memory lane to explore the history of container platforms and their role in modern software development. This journey encompasses early virtualization techniques, groundbreaking innovations in operating systems like FreeBSD, and the rise of contemporary container orchestration systems. ## The Birth of Containers To understand the origins of container platforms, we must first understand the concept of containers themselves. A container is a lightweight, standalone package that contains everything needed to run a piece of software, including code, runtime, system tools, and libraries. This eliminates the need for developers to worry about discrepancies between development and production environments, making it easier to move their applications between different computing environments. Before the advent of containers, virtualization was the primary method for resource partitioning. **Virtual Machines (VMs)** enabled multiple operating systems to run on a single physical machine, each within its isolated environment. This technology transformed data centers by enhancing server utilization and simplifying disaster recovery. Concurrently, the Unix operating system introduced [chroot](https://en.wikipedia.org/wiki/Chroot) in 1979. This command changed the apparent root directory for a running process and its descendants, effectively isolating them from the rest of the system. While not a full-fledged containerization solution, chroot pioneered the concept of process isolation. ## FreeBSD and the Introduction of Jails In 2000, [FreeBSD](https://en.wikipedia.org/wiki/FreeBSD), an advanced open-source operating system, introduced the concept of "jails." FreeBSD jails were a significant advancement over chroot, providing enhanced isolation, security, and resource control. Each jail could run a complete, isolated instance of the operating system, complete with its own IP address, user space, and file system. This feature was particularly useful for hosting providers, as it allowed them to securely run multiple instances of applications or services on a single machine. Jails were an important step towards modern containerization, offering a practical solution for isolating processes and managing resources. They demonstrated the potential of container-like technologies in production environments, especially for scenarios requiring enhanced security and multi-tenancy. However, it was not until the launch of [Docker](https://www.theregister.com/2017/10/17/docker_ee_kubernetes_support/) in 2013 that containers became mainstream. Docker simplified the process of creating, managing, and running containers by providing a standardized format and tools for packaging and running applications, which included an API and command-line interface. This made it easier for developers to build and deploy applications in a consistent and efficient manner. ## The Era of Orchestration: Kubernetes and Beyond As Docker containers gained popularity, managing them at scale became a critical challenge. Kubernetes, initially developed by Google in 2014, emerged as the leading container orchestration platform, providing a robust framework for deploying, scaling, and managing containerized applications. Kubernetes introduced a declarative model, allowing users to define the desired state of their infrastructure, with the system ensuring that the actual state matches the desired state. This automation of operational tasks, such as scaling and failover, was a significant advancement, facilitating the management of large, complex systems. Other popular container platforms soon followed, such as Docker Swarm, Apache Mesos, and Red Hat OpenShift. These platforms offered similar capabilities to Kubernetes, but with their own unique features and approaches. ## The Future of Container Platforms Today, container platforms are integral to cloud-native architectures. The ecosystem has expanded to include a myriad of tools and services, such as Istio for service meshes, Prometheus for monitoring, and Helm for package management. The Open Container Initiative (OCI) and [Cloud Native Computing Foundation (CNCF)](https://www.cncf.io/) continue to drive standardization and innovation in the field. Looking ahead, container platforms continue to evolve, integrating with technologies like serverless computing, edge computing, and AI/ML workloads. These advancements promise to enhance the flexibility, efficiency, and scalability of IT infrastructures. Additionally, the focus on security and compliance will intensify, with improved tools for monitoring and governance. ## Conclusion The history of container platforms is a journey of continuous innovation, from early virtualization and the pioneering efforts of FreeBSD jails, to becoming the backbone of modern software development, container platforms have come a long way. And with the increasing demand for scalable and efficient software solutions, they are sure to play an even greater role in the future of technology. --- ## How to Streamline Kubernetes Management - **URL:** https://www.kubermatic.com/resources/how-to-streamline-kubernetes-management/ - **Date:** 2024-08-06 - **Description:** Explore how to streamline Kubernetes management to enhance consistency, efficiency, and security while reducing costs and risks. # How to Streamline Kubernetes Management ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Ebook ## Learn how to streamline your Kubernetes Management Managing Kubernetes across various environments poses significant challenges for large enterprises. This white paper explores how to streamline Kubernetes management to enhance consistency, efficiency, and security while reducing costs and risks. By leveraging advanced tools and best practices, enterprises can achieve greater control and visibility over their Kubernetes deployments. If our form couldn't load correctly – This can have multiple reasons like ad blocker, not accepted cookies, JavaScript deactivated. However, you can still get in touch with us! Simply click on the button below, and you'll be able to submit the form and reach out to us for any inquiries or assistance you need. [Open form](https://share.hsforms.com/19HU1koDITLamfKm-8QZ-2A2piu8) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Optimize, Secure, and Automate: Mastering Kubernetes in a Multi-Cloud World - **URL:** https://www.kubermatic.com/resources/optimize-secure-and-automate-mastering-kubernetes-in-a-multi-cloud-world/ - **Date:** 2024-07-30 - **Description:** Discover real-life case studies and practical strategies to transition from legacy infrastructure to a robust, and secure cloud native architecture. # Optimize, Secure, and Automate: Mastering Kubernetes in a Multi-Cloud World ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Explore best practices for automating and securing Kubernetes operations In the modern landscape of cloud computing, managing Kubernetes applications across multi-cloud, edge, and on-prem environments presents unique operational and security challenges. Watch the insightful webinar with Aqua and Kubermatic, where we explore best practices for automating and securing Kubernetes operations. Learn how to empower your DevOps teams to be self-sufficient, optimize resource usage through autoscaling, and avoid vendor lock-in. Discover real-life case studies and practical strategies to transition from legacy infrastructure to a robust, and secure cloud native architecture. Ensure your business is equipped to meet the demands of digital transformation with comprehensive multi-cloud support and best of breed security measures. **Key Takeaways:** - Effective approaches to IT modernization: Lift & Shift, Augment, and Rewrite - Challenges and benefits of each modernization approach - Insights on building a cloud-agnostic platform with managed Kubernetes solutions - Practical demonstrations on automating Kubernetes Operations with Kubermatic - Strategies to secure your cloud native applications with Aqua Security **Speakers:** - Tobias Gerhardt, Solution Architect, Aqua Security - Tobias Schneck, Principal Architect, Kubermatic ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## The Four Phases for a Successful VMware Migration - **URL:** https://www.kubermatic.com/resources/four-phases-for-a-successful-vmware-migration/ - **Date:** 2024-07-19 - **Description:** Ensure a smooth journey to a VMware alternative with our four-phase migration strategy: Uncover, Analyze, Pilot, Plan. # The Four Phases for a Successful VMware Migration ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Whitepaper ## Uncover, Analyze, Pilot, Plan Discover how to transition from VMware and leverage cloud-native solutions for modernization and cost-efficiency. Learn to minimize vendor lock-in, rebalance maintenance and innovation efforts, and adopt open-source practices to create a resilient IT environment. This white paper explores VM migration, lift and shift, and complete rewrites to optimize your application portfolio, with insights on integrating Azure Kubernetes Services and embracing GitOps for streamlined operations. Download our free whitepaper: - See how to make the switch to the right solution for you today and experience a VMware Broadcom migration that is not just smooth but transformative. - Discover three main strategies to modernize an Application Portfolio - Learn how to review your current strategy and bring a COST-EFFICIENT and COST-EFFECTIVE alternative that ensures business success. [Download](/static/White-Paper-The-Death-of-an-industry-standard.pdf) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Addressing Security Challenges and Data Privacy in Edge Environments - **URL:** https://www.kubermatic.com/blog/addressing-security-challenges-and-data-privacy-in-edge-environments/ - **Date:** 2026-04-30 - **Description:** Discover how to address security challenges and ensure data privacy in edge computing environments. - **Categories:** Best Practices - **Tags:** Best Practices - **Authors:** Sebastian Scheele In today's rapidly evolving technological landscape, edge computing has emerged as a pivotal strategy for organizations seeking to enhance their operational efficiency and responsiveness. By processing data closer to the source, edge computing reduces latency, improves real-time decision-making, and minimizes the load on centralized data centers. However, as with any technological advancement, it introduces new challenges, particularly security and data privacy. This blog delves into these challenges and explores risk mitigation strategies in distributed edge environments. ## Understanding the Security Challenges ### 1. Increased Attack Surface The proliferation of edge devices significantly expands the potential attack surface. Each device represents a potential entry point for cyber threats. Ensuring the security of these distributed endpoints is crucial to prevent unauthorized access and data breaches. ### 2. Resource Constraints Edge devices often have limited computational resources compared to traditional data centers. Implementing robust security measures that do not overwhelm these devices is a delicate balancing act. Lightweight yet effective security protocols are essential to maintain performance while safeguarding data. ### 3. Network Vulnerabilities The communication between edge devices and central systems relies on networks that can be susceptible to attacks. Ensuring secure communication channels and protecting data in transit is paramount to prevent interception and tampering. ### 4. Physical Security Unlike centralized data centers, edge devices are often deployed in less controlled environments. This increases the risk of physical tampering or theft, necessitating additional measures to protect the hardware and the data it processes. ## Ensuring Data Privacy ### 1. Data Encryption Encrypting data at rest and in transit is a fundamental step in protecting sensitive information. Strong encryption protocols ensure that even if data is intercepted or accessed by unauthorized parties, it remains unreadable and secure. ### 2. Access Controls Implementing stringent access controls ensures that only authorized personnel and systems can access sensitive data. Multi-factor authentication (MFA), role-based access control (RBAC), and regular access audits help maintain data privacy and integrity. ### 3. Data Minimization Edge computing enables real-time data processing, which reduces the need to transfer large volumes of data to central systems. By minimizing data movement and storage, organizations can reduce the risk of data exposure and enhance privacy. ### 4. Compliance with Regulations Adhering to data privacy regulations such as GDPR, CCPA, and HIPAA is essential for maintaining user trust and avoiding legal repercussions. Regularly reviewing and updating compliance practices ensures that data privacy standards are met. ## Strategies for Mitigating Risks ### 1. Regular Security Audits Conducting regular security audits helps identify vulnerabilities and areas for improvement. Proactive measures like penetration testing and vulnerability assessments can preempt potential threats. ### 2. Edge Device Management Implementing robust device management protocols ensures that all edge devices are regularly updated with the latest security patches and firmware. Centralized management platforms can streamline this process and provide real-time monitoring and control. ### 3. Zero Trust Architecture Adopting a zero-trust security model, which operates on the principle of "never trust, always verify," ensures that every access request is thoroughly authenticated and authorized, regardless of origin. ### 4. AI and Machine Learning Leveraging AI and machine learning can enhance threat detection and response capabilities. These technologies can analyze patterns, detect anomalies, and respond to threats in real time, providing an additional layer of security. ## Conclusion Living at the edge offers unparalleled speed, efficiency, and real-time processing advantages. However, it also presents unique security and privacy challenges that must be addressed to fully harness its potential. Organizations can protect their distributed edge environments by understanding these challenges, implementing robust security measures, and ensuring data privacy. At Kubermatic, we are committed to helping our clients navigate these complexities and build secure, resilient edge computing infrastructures. For more insights and solutions tailored to your edge computing needs, contact us at Kubermatic. Together, we can create a safer, more efficient edge computing landscape. --- ## Digital Transformation Starts in Your Head! - **URL:** https://www.kubermatic.com/blog/digital-transformation-starts-in-your-head/ - **Date:** 2026-04-30 - **Description:** Digital transformation begins with a mindset shift. Discover how embracing change, fostering openness, and maintaining clarity can drive successful transformation. - **Categories:** Company - **Tags:** Announcements - **Authors:** Julian Hansert Digital transformation often conjures images of cutting-edge technology, sleek software solutions, and futuristic innovations. However, at its core, digital transformation is more about mindset than machinery. The true drivers of this transformation are the psychological and motivational factors that empower an organization to navigate change successfully. A clear understanding of goals and the path to achieving them is essential for maintaining competitiveness in today's digital age. This clarity and direction stem from human initiative and a collective willingness to embrace necessary progress. As highlighted in [a recent article on CIO.com](https://www.cio.com/article/2066663/digital-transformations-fundamental-change-management-mistake.html), overlooking these human elements can lead to fundamental change management mistakes that derail transformation efforts. ## Embracing Change – it's a tough one for most people! Change is often met with resistance. People naturally cling to the familiar, finding comfort in routines and established methods. However, digital transformation demands a willingness to step out of comfort zones and explore uncharted territories. This means fostering a culture of openness and adaptability within your organization. To cultivate this mindset, leaders must encourage continuous learning and curiosity. Employees should be motivated to question the status quo and seek innovative solutions. By creating an environment where experimentation and failure are seen as opportunities for growth, organizations can break free from the constraints of traditional thinking. ## Starting with the Vision - The Need for Clarity At the core of every digital transformation is the drive for change – a shift in how we think, work, and interact. As such the psychological readiness and motivation of every person involved in the change project will play a pivotal role in the project's success. Many projects fail because an individual's thoughts, needs, wants, and ability to adapt were not considered as part of the transformation. Digital transformation requires a clear vision and purpose. Ambiguity can lead to confusion and hesitation, stalling progress. Leaders must articulate a compelling narrative that explains the 'why' behind the transformation. This narrative should resonate with all levels of the organization, aligning everyone toward a common goal but it must also have clarity so that every individual can understand the impact to them personally. By giving this practical and personal clarity, employees can understand how new technologies and processes will impact their roles, and providing clear, step-by-step guidance can alleviate fears and build confidence in the transformative journey and their role in achieving its success. ## Openness to New Approaches Openness is essential in embracing digital transformation. This means being receptive to new ideas, feedback, and ways of working. Organizations must dismantle silos and encourage cross-functional collaboration. Diverse perspectives can spark creativity and lead to breakthrough innovations. Moreover, openness involves leveraging data and insights to make informed decisions. Data-driven approaches can uncover hidden opportunities and provide a roadmap for strategic initiatives. By valuing transparency and evidence-based decision-making, organizations can navigate the complexities of digital transformation with confidence. ## Resolute Implementation Having the right mindset is only part of the equation; resolute implementation is equally critical. Digital transformation requires commitment and persistence. Organizations must allocate resources, time, and effort to drive change effectively. Leaders play a crucial role in sustaining momentum. They must lead by example, demonstrating their commitment to the transformation journey. Regular communication and updates can keep the organization aligned and motivated. Recognizing and celebrating milestones along the way can also reinforce a sense of progress and achievement. ## Conclusion Digital transformation starts from your head. The psychological and motivational aspects of change are the foundation upon which successful transformation is built. By fostering clarity, openness, and resolute implementation, organizations can navigate the complexities of the digital age. Embracing radical shifts in thinking and working can unlock new possibilities and drive sustainable success. As we embark on this transformative journey, remember that the most powerful tool at our disposal is our mindset. --- ## Edge Computing - **URL:** https://www.kubermatic.com/topics/edge-computing/ - **Date:** 2024-07-15 - **Description:** Explore how edge computing benefits sectors like manufacturing, retail, healthcare, and telecommunications by providing faster data processing and reduced network traffic. # Edge Computing ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Jump To Section [What is edge computing?](#what-is-edge-computing) [Introduction to Containers and Edge Computing](#introduction-to-containers-and-edge-computing) [What does Industrial Edge mean?](#what-does-industrial-edge-mean) [Cloud vs. Edge Computing](#cloud-vs-edge-computing) ## What is edge computing? Edge computing is a computing framework that brings data processing and storage closer to the source of the data, rather than relying on a central location like a cloud data center. It involves pushing computation and storage resources to the “edge” of the network, which can include devices such as routers, gateways, and even user devices like smartphones. This allows for faster data processing, lower latency, and reduced network traffic. [Edge Computing](/blog/exploring-containers-and-edge-computing/) entails bringing computing resources and data storage closer to data sources to improve response times, save bandwidth, and unlock new business opportunities across various sectors, such as manufacturing, retail, healthcare, and telecommunications. ## Introduction to Containers and Edge Computing Containers and Edge Computing are closely linked in terms of delivering efficient, scalable, and reliable computing solutions. Containers provide a lightweight and portable platform for deploying applications, allowing developers to bundle and isolate applications along with their entire runtime environment. This isolation makes it easier to manage and move applications across different computing environments, which is particularly useful in edge computing. Edge computing deploys data processing to the edge of a network - closer to where the data originates. This approach reduces network latency, bandwidth usage, and data transmission costs, leading to improved real-time analytics and decision-making. The combination of containers and edge computing enables businesses to deploy and run applications faster, more reliably, and at a grander scale, no matter where the computing resources are situated. ## What does Industrial Edge mean? Industrial Edge refers to the application of edge computing in industrial settings, aiming to perform data processing near or at the source within an industrial environment. It allows industries to handle complex computations close to machinery, automate real-time operations, reduce long-distance communication between clients and servers, and enhance data privacy and security. ## Cloud vs. Edge Computing The main difference between cloud and edge computing is the location of data processing and storage. Cloud computing relies on a centralized data center, while edge computing distributes these resources to the “edge” of the network. Cloud computing is better suited for handling large amounts of data and complex workloads, while edge computing is ideal for real-time processing and low-latency applications. Both cloud and edge computing have their benefits and can complement each other in certain scenarios. --- ## Cloud Computing - **URL:** https://www.kubermatic.com/topics/cloud-computing/ - **Date:** 2026-02-13 - **Description:** Discover how cloud computing allows you to access and store data, applications, and services online, providing a flexible, scalable, and cost-effective solution for individuals and businesses. # Cloud Computing ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Jump To Section [What is cloud computing?](#what-is-cloud-computing) [What is a cloud infrastructure?](#what-is-a-cloud-infrastructure) [Examples of Cloud Providers](#examples-of-cloud-providers) [Common Use Cases for Cloud Computing](#common-use-cases-for-cloud-computing) [What are Hybrid and Multi-cloud Kubernetes](#what-are-hybrid-and-multi-cloud-kubernetes) [Hybrid and Multi-cloud Kubernetes: Benefits and Challenges](#hybrid-and-multi-cloud-kubernetes-benefits-and-challenges) [On-Premise vs. Cloud Computing: Key Differences, Benefits and Risks](#on-premise-vs-cloud-computing-key-differences-benefits-and-risks) [Impact of On-Premises vs. Cloud Computing on IT Infrastructure](#impact-of-on-premises-vs-cloud-computing-on-it-infrastructure) ## What is cloud computing? Cloud computing is a technology that allows users to access and store data, applications, and services over the Internet instead of on a physical device or server. This means that users can access their data and programs from anywhere with an internet connection, without the need for specialized hardware or software. It also offers a flexible and scalable solution as users can easily scale up or down their storage and computing needs depending on their requirements. Cloud computing has become a popular choice for individuals and businesses due to its convenience, cost-effectiveness, and ease of use. It eliminates the need for maintaining physical infrastructure, reduces IT costs, and allows for greater flexibility and collaboration. ## What is a cloud infrastructure? A cloud infrastructure is a virtual environment created through a network of remote servers and storage systems that allow for the storage, management, and delivery of various computing services over the internet. This infrastructure allows individuals and organizations to access resources such as compute power, storage, networking, and software applications on demand, without the need for physical hardware. It serves as the backbone for cloud computing, making it possible for users to access data and applications anytime and anywhere. It is highly scalable, secure, and cost-effective, as users only pay for the resources they use, enabling businesses to be more agile and flexible in meeting their computing needs and making it a popular choice for many industries. With a cloud infrastructure, organizations can reduce their IT costs, increase efficiency, and focus on their core business operations. Cloud computing offers various services that cater to different needs and use cases, which are generally categorized into three primary types: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). *Infrastructure as a Service (IaaS)* is the most fundamental cloud service model that provides virtualized computing resources over the Internet. It essentially offers the infrastructure — such as servers, storage, and networking — needed to deploy and run applications and operating systems. *Platform as a Service (PaaS)* is a cloud computing model that provides a framework for developers to build, deploy, and manage applications without worrying about the underlying infrastructure. PaaS includes everything needed to support the complete lifecycle of building and delivering web applications and services entirely from the Internet. *Software as a Service (SaaS)* is a cloud computing model that delivers software applications over the internet, on a subscription basis. With SaaS, the software is hosted and maintained by the service provider, making it accessible. ## Examples of Cloud Providers When exploring cloud services, you might consider some of the most popular cloud providers in the industry. These include: *Amazon Web Services (AWS):* Renowned for its vast array of services and global infrastructure, AWS offers everything from computing power and storage to machine learning and IoT. *Microsoft Azure:* Known for its seamless integration with Microsoft products, Azure provides a wide range of cloud solutions for computing, analytics, storage, and networking. *Google Cloud Platform (GCP):* GCP stands out for its strong capabilities in data analytics, machine learning, and scalable infrastructure, along with a variety of other cloud services. Each of these providers offers unique services and features, making them suitable for different business needs and technical requirements. ## Common Use Cases for Cloud Computing Cloud computing is versatile and can be applied to numerous scenarios across various industries. Here are some common use cases: **1. Web Hosting:** - Websites and Applications: Hosting websites and web applications on the cloud allows for scalability, reliability, and global reach. Cloud providers offer managed services that handle server maintenance, security, and backups. - Content Delivery: Cloud-based Content Delivery Networks (CDNs) improve the speed and performance of websites by distributing content across multiple locations. **2. Data Storage:** - File Storage: Cloud storage solutions enable users to store, manage, and access files and data remotely. Services like Amazon S3, Google Cloud Storage, and Azure Blob Storage provide scalable and secure storage options. - Database Hosting: Cloud databases offer scalable and managed database services, making it easier to handle large volumes of data and high transaction rates without worrying about infrastructure maintenance. **3. Disaster Recovery:** - Backup Solutions: Cloud-based backup services ensure that critical data is regularly backed up and can be quickly restored in case of data loss due to hardware failures, cyber-attacks, or natural disasters. - Business Continuity: Cloud disaster recovery solutions provide a failover environment where applications and data can be quickly restored, minimizing downtime and ensuring business continuity. **4. Software Development and Testing:** - Development Environments: Developers can use cloud-based environments to build, test, and deploy applications without the need for on-premises infrastructure. This promotes collaboration and speeds up development cycles. - CI/CD Pipelines: Continuous Integration and Continuous Deployment (CI/CD) pipelines hosted in the cloud automate the process of code integration, testing, and deployment, enhancing efficiency and reducing errors. **5. Big Data and Analytics:** - Data Processing: Cloud platforms offer powerful tools and services for processing large datasets, enabling businesses to gain insights and make data-driven decisions. - Machine Learning: Cloud-based machine learning services provide the infrastructure and tools needed to build, train, and deploy machine learning models at scale. These use cases illustrate how cloud computing can enhance operational efficiency, reduce costs, and provide scalable solutions for various business needs. ## What are Hybrid and Multi-cloud Kubernetes Hybrid and Multi-cloud Kubernetes refers to a deployment model where Kubernetes, a popular container orchestration platform, is used to manage both on-premises and cloud-based environments simultaneously. This allows organizations to have a unified infrastructure across multiple environments, bringing together the benefits of both on-premises and cloud computing. Hybrid Kubernetes involves deploying Kubernetes on both private and public cloud infrastructure, combining the control and security of on-premises environments with the flexibility and scalability of the cloud. This allows organizations to have a more diverse and flexible deployment architecture. Multi-cloud Kubernetes, on the other hand, refers to deploying multiple Kubernetes clusters across different cloud environments such as AWS, Microsoft Azure, Google Cloud, etc. This gives companies the ability to distribute their applications and workloads across multiple cloud providers, reducing the risk of vendor lock-in and allowing for seamless migration between environments. ## Hybrid and Multi-cloud Kubernetes: Benefits and Challenges As organizations look to leverage the advantages of multiple cloud environments, hybrid and multi-cloud Kubernetes deployments have emerged as powerful solutions. By combining on-premises, private cloud, and multiple public cloud resources, these strategies offer enhanced flexibility, scalability, and resilience. However, they also come with their own set of challenges. **Benefits:** - Hybrid and multi-cloud Kubernetes provide significant flexibility and agility by allowing workload distribution across on-premises, private, and public clouds. This helps avoid vendor lock-in and leverage the best services from various providers. - The scalability offered by Kubernetes ensures optimal resource utilization and application performance, while a global reach reduces latency and improves user experience. Additionally, this approach enhances disaster recovery and high availability by replicating workloads across different environments. - Cost optimization is another advantage, as organizations can choose the most cost-effective solutions and dynamically allocate resources, reducing unnecessary expenses. **Challenges:** - Networking across multiple cloud environments can be complex, requiring advanced solutions to ensure seamless communication. - Latency and bandwidth limitations between clouds may impact performance. - Ensuring consistent security policies and protecting data across different environments is challenging, necessitating robust encryption and access controls. - Managing costs across multiple providers is difficult without comprehensive tools, and unexpected expenses can arise from varying pricing models. - Operating Kubernetes clusters in hybrid and multi-cloud setups increases operational complexity, requiring skilled personnel and advanced monitoring and automation tools. ## On-Premise vs. Cloud Computing: Key Differences, Benefits and Risks On-premises computing involves storing data on servers located physically within a company’s premises. In contrast, cloud computing involves storing data on remote servers and accessing it via the Internet. On-premises computing offers more control and security but requires high upfront capital expense, IT expertise, and ongoing management. Cloud computing, on the other hand, offers scalability, lower upfront costs, and access to advanced technologies, but it depends on an internet connection and may have potential security vulnerabilities. ## Impact of On-Premises vs. Cloud Computing on IT Infrastructure On-premises computing impacts IT infrastructure by requiring more physical resources, including servers, storage, and networking hardware within the organization. It also necessitates having the technical expertise in-house to manage and troubleshoot the infrastructure. In contrast, cloud computing reduces the organization’s hardware needs as resources are rented from a cloud services provider. It also potentially lowers staffing needs as the provider typically handles maintenance, but it can necessitate stronger bandwidth and internet infrastructure to ensure uninterrupted service. --- ## Why Securing Containers Feels Like Renovating Your Home - **URL:** https://www.kubermatic.com/blog/why-securing-containers-feels-like-renovating-your-home/ - **Date:** 2026-04-30 - **Description:** Guard your digital fortress with a strong security framework, patch vulnerabilities to prevent breaches, reinforce your defenses with updates, and monitor continuously for optimal performance. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Sebastian Scheele As everyone knows, owning a house comes with the ongoing set of regular maintenance. Whether it's fixing a leaky tap or discovering you need a new roof. Maintenance or more costly work is a regular part of our day-to-day home life. Like our houses, our Container environment also needs this level of regular attention to ensure a robust and secure digital infrastructure. Just as regular home maintenance ensures your house remains sturdy and safe, securing containers protects your digital ecosystem from potential threats. As such there are key elements that are important to protecting your container environment: ## Guarding Your Digital Fortress: Installing a Security System Imagine setting up a security system for your home to protect against intruders. Similarly, securing your containers requires a robust security framework to defend against cyber threats. According to a report by Cybersecurity Ventures, cybercrime is expected to cost the world $10.5 trillion annually by 2025, underscoring the critical need for strong security measures. Much like installing cameras and alarms, implementing security policies and access controls in your container environment can deter malicious activities. This involves setting up role-based access controls (RBAC), network policies, and ensuring that only authorized personnel can interact with critical components of your infrastructure. ## Patching Vulnerabilities: Fixing Leaky Pipes Imagine discovering a leaky pipe in your home. Ignoring it could lead to water damage, mold growth, and costly repairs. Similarly, leaving vulnerabilities in your containerized applications unaddressed can expose your system to data breaches and cyber-attacks. According to a study by IBM, the average cost of a data breach in 2023 was $4.45 million, highlighting the financial risks of inadequate security measures. In the same way you'd call a plumber to fix a leaky pipe, IT professionals must regularly they are aware and ensure the patching of any vulnerabilities in their containers. By being proactive you prevent minor issues from escalating into major security incidents, ensuring the integrity and performance of your applications in your container environment. ## Regular Updates: Reinforcing Your Roof When a storm is coming you may worry about your home's roof, thinking about software updates is perhaps the equivalent in your container environment. In 2023, it was reported that 60% of companies experienced container-related security incidents, often due to outdated software. Regular updates and security patches fortify your containers against new and evolving threats and make sure you narrow security gaps and maintain a robust defense against cyber threats. ## Monitoring and Maintenance: Routine Inspections Just as you schedule routine inspections for your home's HVAC system or electrical wiring, continuous monitoring and maintenance are vital for container security. Tools like Kubernetes, combined with a robust security strategy, can help identify and mitigate potential issues before they become critical. ## Choosing the Right Materials and Vendors for House Repairs: As Critical as Picking the Right Container Platform When you choose a supplier for fixing your home – you will look for the best. It's no different when you're choosing the right platform for your container environment. When it's time to review or look at vendors here are some of the key factors you should consider: 1. **Security Features**: Look for vendors that offer comprehensive security features such as automated security patches, integrated monitoring, and threat detection. 2. **Scalability**: Ensure the vendor can support your growth by providing scalable solutions that can handle increasing workloads. 3. **Compliance**: The vendor should comply with industry standards and best practices to ensure your container environment meets regulatory requirements. 4. **Ease of Use**: The platform should be user-friendly, allowing for easy management and deployment of containers. 5. **Support and Community**: Choose a vendor with robust support options and an active community to help resolve issues quickly and efficiently. Kubermatic, with its Kubernetes Platform, is an excellent choice that meets these criteria. It automates the deployment, operation, and scaling of Kubernetes clusters across any environment, enhancing security through consistent and repeatable processes. ## Conclusion While we joke about the reference to owning a home, there are huge similarities to your container environment. Regular maintenance, updates, and proactive measures are essential to protect your digital infrastructure from potential threats. With the right tools and strategies, such as those offered by Kubermatic, businesses can achieve a secure and resilient container environment, safeguarding their valuable data and applications. Just as a well-maintained home provides safety and comfort, a secure container ecosystem ensures the stability and integrity of your digital operations. So, I recommend you embrace the analogy and prioritize container security as you would your home's upkeep, and you'll be well-equipped to handle the challenges of the modern IT landscape. --- ## The Future of AI/ML in Kubernetes: Trends and Best Practices - **URL:** https://www.kubermatic.com/blog/ai-and-machine-learning-integration-into-kubernetes/ - **Date:** 2026-06-10 - **Description:** Discover the latest trends, challenges, and best practices for integrating AI and machine learning into Kubernetes. Learn how to optimize scalability, flexibility, and automation for AI/ML workloads. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Sebastian Scheele AI technology is a common place in the everyday world now and as it converges, cloud computing and AI/ML will unleash enormous value and disrupt most industries. The cloud platforms serve all the necessary infrastructure and resources for training and deploying AI/ML models at scale. Kubernetes is ideally positioned to take the lead, acting as a critical enabler to AI/ML workloads regarding scalability, flexibility, and automation. ## Key Trends in AI/ML Integration with Kubernetes The integration of AI/ML with Kubernetes is characterized by several key trends that enhance deployment, management, and scalability of workloads: * **Containerization of AI/ML workloads**: Here, containers bundle AI/ML models with their dependencies into a single portable unit. Doing this ensures consistency across different environments, easing the deployment and management of those models. Therefore, Kubernetes has become a perfect platform for deploying AI/ML. * **Automated machine learning pipelines**: Kubernetes allows the automation of end-to-end machine learning pipelines, from data ingestion and preprocessing to model training and deployment. Tools like Kubeflow and MLflow make this an easy process when automated on Kubernetes. * **Scalability and Resource Management**: Kubernetes provides dynamic scaling to assure that the resources required by AI/ML workloads can be well managed—that the models can deal with different loads and demands seamlessly, without manual interference. * **Edge AI/ML**: With the rise of edge computing, there are use cases that have popped up where Kubernetes is leveraged for the deployment of AI and ML models very close to the source of data. This minimizes latencies and boosts their real-time processing capabilities. ## Major Challenges in AI/ML Integration with Kubernetes Despite its many advantages, integrating AI/ML with Kubernetes presents several significant challenges that organizations must navigate: * **Setup and management of Kubernetes AI/ML workloads** could become highly complex, necessitating a deep level of expertise in both Kubernetes and AI/ML. This last aspect could end up being a bottleneck for adoption by organizations without dedicated resources. * **Resource Allocation and Optimization**: AI/ML workloads are heavy on resources; therefore, these resources need to be allocated and optimized carefully to avoid contention for resources, preventing a waste of resources. * **Security and Compliance**: The security and compliance of AI/ML models and data in the Kubernetes environments will continue to be crucial. The organization has to establish stringent security controls for safeguarding any loss of sensitive information and breaching regulations. * **Monitoring and Maintenance**: AI/ML models require continuous monitoring and maintenance to be sure of the correct performance and accuracy of the models. Kubernetes offers some of the monitoring frameworks and tools upon integration, which serve the purpose perfectly. ## Best Practices for AI/ML Integration with Kubernetes To effectively integrate AI/ML with Kubernetes, organizations should consider some of these best practices to ensure optimal performance, scalability, and security: * **Use a Modular Approach**: Segment AI/ML pipelines into modular components and containerize each step for better flexibility and manageability. This approach is quickly done during troubleshooting to improve scalability. * **Leverage Kubernetes Native Tools**: Leverage Kubernetes-native tools to manage AI/ML workloads, such as Kubeflow, TensorFlow Serving, and Seldon. These tools enable out-of-the-box integrations and extensions designed explicitly for Kubernetes environments. * **Implement robust CI/CD pipelines**: Setting up CI/CD pipelines for automatic testing and deployment of AI/ML models is essential. It would facilitate making such iterations quick and reliable while rolling out model updates. * **Resource management optimization**: Leverage the resources properly using features like quotas, limits, and horizontal pod autoscaling within Kubernetes to optimize the allocation of resources so that there is no overprovisioning or underutilization. * **Focus on security and compliance**: Implement strong security measures, including network policies, encryption, access controls, audits, and updates with consideration for changing regulations. ## Kubermatic: How They Leverage AI/ML Integration with Kubernetes As AI/ML and Cloud converge, Kubermatic has been working to provide many options for organizations to embed AI/ML technologies into their Kubernetes landscape easily. Tools for the automated deployment, scaling, and management of AI/ML workloads allow Kubermatic to address many challenges that organizations encounter. * **Automated Pipeline Management**: Automate your AI/ML pipelines easily and set yourself free from the headache of setting them up with Kubermatic. * **Scalable Infrastructure**: Through this platform, resource optimization for AI/ML workloads is achieved by providing the ability to auto-scale functionalities dynamically. * **Security and Compliance**: Kubermatic provides robust built-in features for security to secure AI/ML models and data to keep organizations compliant with existing regulations. * **Rich Monitoring**: It provides integrated monitoring and alerting tools that provide continuous oversight on the health and performance of the AI/ML models. ## Conclusion There is genuinely immense scope for innovations and efficiencies in the industry with the integration of AI/ML technologies in the Kubernetes ecosystem. There will be challenges, of course, but with best practices in the industry and an enabling platform such as Kubermatic, the exercise becomes much more approachable. The future of intelligent applications will be shaped mainly by Kubernetes as synergy between cloud computing and AI/ML continues to rise. Organizations will open up new potentials of performance and scalability by embracing Kubernetes with AI/ML, providing an edge in a fast-evolving landscape. As you consider embracing Kubernetes and AI/ML, reach out to us to discuss how we can support your journey. Check out other related useful articles: * [https://www.kubermatic.com/blog/scaling-ml-with-kubermatic-kubernetes-platform/](/blog/scaling-ml-with-kubermatic-kubernetes-platform/) * [https://www.kubermatic.com/solutions/build-cloud-native-ai-and-ml/](/solutions/build-cloud-native-ai-and-ml/) ## FAQs **What are the benefits of integrating AI/ML with Kubernetes?** Integrating AI/ML with Kubernetes offers benefits such as scalability, flexibility, and automation of workloads. It enables consistent deployment across environments and efficient resource management. **How does Kubernetes improve AI/ML scalability?** Kubernetes improves scalability by dynamically adjusting resources based on demand. This ensures optimal performance under varying loads and reduces the need for manual intervention. **What tools can be used for AI/ML integration in Kubernetes?** Tools such as Kubeflow, TensorFlow Serving, and Seldon are commonly used for integrating AI/ML with Kubernetes. These tools offer seamless integration and automation capabilities. **What are common challenges in AI/ML and Kubernetes integration?** Common challenges include complex setup and management, resource allocation and optimization, security and compliance, and continuous monitoring and maintenance of models. **How can security be ensured in AI/ML Kubernetes environments?** Security can be ensured by implementing network policies, encryption, access controls, regular audits, and staying updated with security patches. Compliance with regulations is also crucial. **What are best practices for managing AI/ML workloads in Kubernetes?** Best practices include using a modular approach, leveraging Kubernetes-native tools, implementing CI/CD pipelines, optimizing resource management, and focusing on security and compliance --- ## IoT and Kubernetes: Is a Happy Marriage Possible? - **URL:** https://www.kubermatic.com/blog/iot-and-kubernetes/ - **Date:** 2026-04-30 - **Description:** Kubernetes is becoming increasingly significant. Explore the connection between Kubernetes, Edge computing, and networking within the concept of Industry 4.0. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Sebastian Scheele ## Kubernetes, Edge, and Networking in Industry 4.0 Kubernetes, the popular open-source container orchestration system, is becoming increasingly significant. This article explores the connection between Kubernetes, Edge computing, and networking within the concept of Industry 4.0. ## Can Kubernetes Be Used at the Edge for IoT Applications? Industry 4.0 marks the digital transformation of industrial enterprises, where IT (Information Technology) and OT (Operational Technology) are increasingly merging and resulting in greater complexity. As a well established and proven IT tool, Kubernetes, is one option that can help address the challenges associated with this IT-OT convergence. Known for its effectiveness in cloud and on-premises environments, Kubernetes excels at deploying, scaling, and managing container applications and although often seen as a cloud operating system, Kubernetes is also well-suited for Edge scenarios. Edge computing, which is often linked with Industry 4.0 and the growing Internet of Things (IoT), refers to distributed processing and data storage closer to IoT sensors. When sensors generate large amounts of data, it makes sense to have the corresponding database closer to the sensor rather than pushing everything to the cloud, where latencies are higher and traffic is often charged. Data storage, like IoT sensors, gathers and manages information for remote device operation and real-time data sharing. It is used in applications where data transmission is complex or low latency is critical. With Kubernetes at the Edge, containerized applications can be brought closer to the data source, allowing companies to benefit from cloud-like advantages in terms of easy deployment, scaling, orchestration, and management. ## Challenges of Edge Environments Given that both hardware and software are spread across hundreds or thousands of locations, standardization and automation enabled by cloud-native technologies are the only ways to manage these distributed systems. However, companies looking to use Kubernetes for their Edge computing implementations must consider the challenges specific to Edge environments. Edge definitions can vary, often depending on use case and network position. One common definition is Near Edge, which, in Industry 4.0, refers to local data storage and processing near machines and systems. These devices often control machines and systems in real-time. Edge Gateways connect sensors and actuators, visualizing production data locally, often using Industrial PCs (IPCs) directly in the production environment. This environment typically has fixed resource usage. In this scenario, a full-fledged cluster would be the wrong choice as it would not be highly available and would bring increased overhead. Additionally, the automatic updating and provisioning of IPCs present another challenge. Devices must be updated and quickly reset in case of errors. Vanilla Kubernetes would fall short in these areas, necessitating a new approach within Kubernetes. ## Cloud Management - Renovating the IT Landscape with Kubernetes ## Making Kubernetes "Edge Ready" For companies that want to harness the advantages of Kubernetes at the Edge, there are architectural approaches to overcome challenges and make Kubernetes "Edge Ready." The objective is to streamline and enhance Kubernetes management at the Edge, making it leaner and more efficient. A Kubernetes cluster consists of the control plane and the worker nodes. Think of Kubernetes as two independent parts: a central part for control and a distributed part for data processing. The worker nodes run the applications, while the control plane manages the installation and maintenance of workloads within the cluster. Once a workload has been scheduled to a Kubernetes node, the control plane is not needed, as it only handles lifecycle management. If a worker node loses connection to the control plane, the workloads can still function and run; they just cannot be updated. It is crucial to ensure that the workload can continue running on the cluster and remains accessible from the device itself. This can be achieved through effective caching of the API server. The critical point often occurs when the connection to the cluster is re-established, and reorganization begins. It is essential to ensure that everything remains in the correct place during this process. In this context, the functional unit of a Kubernetes cluster can be thought of as worker nodes with a Kubelet. The centralized management of the control plane is not always necessary for the workload to function. However, this feature is not part of a Vanilla Kubernetes distribution. Kubernetes management platforms make this easily achievable. They often provide additional benefits such as a single pane of glass for centralized management, policy enforcement, and offline capabilities. ## Container Management ## Kubernetes at the Edge Works with the Right Management Platform Kubernetes at the Edge becomes feasible with a Kubernetes management platform that orchestrates parallel workloads and dynamically allocates infrastructure. This allows companies to deploy containers without needing to purchase new hardware or invest in costly software licenses. Existing resources can be reused and optimally allocated, enabling companies to leverage the benefits of containerization at the Edge. A fully automated workflow eliminates the need for manual intervention, ensuring high availability at all times. Additionally, the management layer consumes only a fraction of the computing power compared to other platforms. Administrators benefit from an intuitive user interface and an API, enabling mass deployment across multiple clusters. These platforms often support lightweight Edge deployments as well as hybrid systems in data centers and the cloud. Companies can maximize their existing investments by deploying the platform on their Edge nodes while maintaining enterprise-level security, scalability, and reliability. A platform built from the ground up with a microservices architecture also allows software updates to be rolled out with minimal downtime or service interruptions. With this setup companies, aiming for Industry 4.0, can ensure a seamless integration of IoT and Kubernetes. --- ## Join our BDR Team at Kubermatic! - **URL:** https://www.kubermatic.com/company/careers/join-our-bdr-team/ - **Date:** 2026-07-02 - **Description:** Are you ready to embark on an exciting sales career journey? Join Kubermatic now and receive training in enterprise sales. # Join our BDR Team! Are you ready to kickstart your career in sales? Look no further! Join Kubermatic now and receive training in enterprise sales. [Apply Now](https://kubermatic.bamboohr.com/careers/10) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) --- ## Minimize the Carbon Footprint of Your Data Center - **URL:** https://www.kubermatic.com/resources/minimize-the-carbon-footprint-of-your-data-center/ - **Date:** 2024-06-19 - **Description:** Learn all the benefits of reducing the carbon footprint on your data center and discover the 5 steps you need to take to achieve it. # Minimize the Carbon Footprint of Your Data Center ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Ebook ## Learn how to Minimize the Carbon Footprint of Your Data Center: Consume Less & Achieve More Data centers are powerhouses of the modern world. Housing our web servers, application infrastructure, and even low-level storage, they underpin almost every service we touch in our lives. But we can’t escape the fact that data centers are also extremely energy-intensive. Discover in this ebook how by minimizing energy consumption in your data center, you can maximize cost savings and productivity, while significantly reducing your carbon footprint. This is your chance to learn the 5 steps on how to consume less while achieving more. If our form couldn't load correctly – This can have multiple reasons like ad blocker, not accepted cookies, JavaScript deactivated. However, you can still get in touch with us! Simply click on the button below, and you'll be able to submit the form and reach out to us for any inquiries or assistance you need. [Open form](https://share.hsforms.com/1qmGQYPbQRiu7WIgpWy_IvQ2piu8) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Understanding the NIS 2 Directive: How Kubermatic is Leading the Way - **URL:** https://www.kubermatic.com/blog/understanding-the-nis-2-directive/ - **Date:** 2026-04-30 - **Description:** Understand what is the NIS 2 Directive and how Kubermatic is dedicated to staying ahead in helping organizations meet its stringent requirements. - **Categories:** Community, Best Practices - **Tags:** Kubernetes, Open Source Projects - **Authors:** Sebastian Scheele In 2024, the cybersecurity landscape has seen significant increases in threats and vulnerabilities. According to the CrowdStrike Global Threat Report, there was a 75% increase in cloud intrusions, highlighting the growing challenge of securing cloud environments. Adversaries are using sophisticated techniques, such as abusing valid credentials and leveraging generative AI for more effective phishing and social engineering attacks​ ([CrowdStrike](https://www.crowdstrike.com/global-threat-report/))​ The Deloitte Cybersecurity Threat Trends Report also underscores the rise in threats, noting a 400% increase in IoT malware attacks, with ransomware affecting 66% of organizations in 2023. These figures illustrate the escalating complexity and frequency of cyber threats​ ([Deloitte United States](https://www2.deloitte.com/us/en/pages/risk/articles/cybersecurity-threat-trends-report-2024.html))​. Additionally, the SonicWall Cyber Threat Report recorded a staggering 659% increase in cryptojacking attacks in 2023, driven by the exploitation of cryptocurrency mining through unauthorized use of victims' hardware​ ([SonicWall](https://www.sonicwall.com/threat-report/))​. In an era where cybersecurity threats are continually evolving and increasing, the NIS 2 Directive marks a significant step forward in enhancing the resilience of essential services and digital infrastructure across Europe and regulations that will affect every business. To effectively navigate the complex regulatory landscape, it's crucial to understand the implications of the NIS 2 Directive on your IT infrastructure and processes. As well as, ensuring you collaborate with leading technology providers, like [Kubermatic](/), who are addressing these new requirements as part of their platform development. ## But, What is the NIS 2 Directive? As an update to the original Network and Information Security Directive, the NIS 2 Directive aims to bolster the cybersecurity of essential services, digital service providers, and critical infrastructure within the EU. This directive mandates stricter security measures, improved incident reporting, and more robust risk management practices. Its goal is to ensure a higher level of protection against cyber threats and enhance the overall resilience of the EU's digital landscape. ## What are the Key Requirements of NIS 2 1. **Enhanced Cybersecurity Measures**: Organizations must implement comprehensive security measures, including risk management, incident response, and business continuity planning. 2. **Improved Incident Reporting**: Companies are required to report significant incidents to the relevant authorities within 24 hours, ensuring a timely and coordinated response. 3. **Stricter Compliance and Penalties**: Non-compliance with NIS 2 can result in substantial fines and sanctions, emphasizing the importance of adhering to the directive. ## How is Kubermatic Addressing NIS 2? Kubermatic is dedicated to staying ahead in helping organizations meet the stringent requirements of the NIS 2 Directive. We ensure compliance and enhance cybersecurity by: ### 1. Building a Robust and Comprehensive Security Framework Kubermatic security framework aligns with the NIS 2 Directive's requirements and includes advanced security features such as: * **Automated Security Policies**: Kubermatic enables the automatic enforcement of security policies across all Kubernetes clusters, ensuring consistent and comprehensive protection. * **Regular Security Audits**: Regular audits and vulnerability assessments are conducted to identify and mitigate potential security risks proactively. ### 2. Enhanced Incident Response Kubermatic's platform is designed to streamline incident response processes, ensuring that organizations can quickly detect, report, and respond to security incidents. Key features include: * **Real-Time Monitoring and Alerts**: Continuous monitoring of all Kubernetes clusters with real-time alerts for any suspicious activities or potential threats. * **Integrated Incident Management**: Seamless integration with incident management systems to facilitate rapid and coordinated responses to security incidents. ### 3. Risk Management and Compliance To help organizations manage risks and ensure compliance with NIS 2, Kubermatic offers: * **Risk Assessment Tools**: Comprehensive tools for assessing and managing risks across all Kubernetes environments. * **Compliance Reporting**: Automated compliance reporting capabilities that simplify the process of demonstrating adherence to NIS 2 requirements. ## Case Study: Kubermatic in Action with NIS 2 and Kubernetes A leading European [financial services provider](/customers/interhyp/) leveraged Kubermatic's Kubernetes Platform to enhance their cybersecurity posture and ensure compliance with the NIS 2 Directive. By adopting Kubermatic's automated security policies and real-time monitoring capabilities, the provider was able to: * Reduce the time to detect and respond to security incidents by 50%. * Achieve full compliance with NIS 2 requirements ahead of schedule. * Enhance overall security resilience, mitigating the risk of significant cyber threats. ## Conclusion The NIS 2 Directive represents a pivotal moment in the evolution of cybersecurity standards within the EU. By partnering with technology leaders like Kubermatic, organizations can navigate this complex regulatory landscape with confidence. Kubermatic's comprehensive security framework, enhanced incident response capabilities, and robust risk management tools ensure that businesses not only comply with NIS 2 but also strengthen their overall cybersecurity posture. As the digital threat landscape continues to evolve, staying ahead of regulatory requirements and adopting best-in-class security practices is essential. With Kubermatic, organizations are well-equipped to meet the challenges of the NIS 2 Directive and safeguard their digital infrastructure against the ever-present threat of cyberattacks. --- ## Containers Also Need Backups - **URL:** https://www.kubermatic.com/blog/containers-also-need-backups/ - **Date:** 2026-04-30 - **Description:** Learn how you can expand your container approach and build a reliable backup strategy with KKP - **Categories:** Products - **Tags:** KKP - **Authors:** Sebastian Scheele Since containers are inherently designed to exist only when needed, backing them up requires special considerations. ## A Container Management Solution that’s also for Backups The [Kubermatic Kubernetes Platform](/products/kubermatic-kubernetes-platform/) (KKP) sets the standard for managing container backups efficiently. In addition to essential features like role-based access control (RBAC), authentication, real-time logging, and SSH key management, KKP includes automated backup capabilities. Our latest release, version 2.25, enhances the management of Kubernetes clusters and persistent volumes, ensuring seamless backups, restorations, and migrations across both on-premises and public cloud environments. Regular backups and the deletion of outdated backups, can be fully automated, removing the need for tedious manual tasks. KKP utilizes the Kubernetes backup tool Velero and, by leveraging this Kubernetes API, volumes and snapshots can be created on a custom storage target. Plus, project owners can now manage all backup settings themselves, which is a significant improvement to the previous backup integration that required platform administrators to access the Kubernetes etcd database. This container backup feature is ideal for disaster recovery and the migration of Kubernetes clusters. ## Four Key Aspects of Container Backup At Kubermatic, we have several key aspects in our KKP product we feel are crucial for container backups: ### 1. Planning Automated Regular Backups The KKP-Velero integration allows project owners to centrally manage user cluster backups through a simple interface. They can define multiple cluster backup storage locations as needed and assign them to user clusters. Backup schedules can be defined per cluster to ensure timely backups and restorations. ### 2. Secure Storing of Backups Separately from the Cluster The KKP interface enables project owners to manage all cluster backup storage locations, usable by all clusters in the same project. When cluster backup is enabled for a user cluster, KKP deploys a managed instance of Velero on the user cluster and passes the necessary Velero BackupStorageLocation to the user cluster, with a specific prefix to avoid collisions with other user clusters using the same storage. ### 3. Backing Up Namespaces Separately for Better Granularity Project owners can choose to back up and restore specific namespaces within the clusters. When creating a backup, they can select the namespaces they want to include from a dropdown list fetched directly from the cluster. Users need to create namespaces before configuring the backup. Users can set the backup expiration period, which defaults to 30 days, and decide whether to back up persistent volumes. ### 4. Regularly Testing Restorations When creating a restoration, users can easily set a name for the restoration request and select the namespaces they want to restore. It is possible to track the restoration status and regularly verify if the restoration works as intended. ## Conclusion Utilising KKP from Kubermatic, companies can now expand their container strategy and build a reliable backup strategy to enable the restoration of business data in case of an emergency. --- ## Future Proofing your Company Going Cloud Native - **URL:** https://www.kubermatic.com/resources/future-proofing-your-company-going-cloud-native/ - **Date:** 2024-06-13 - **Description:** Discover how going cloud-native can future-proof your company by enhancing agility, reducing operational costs, and fostering innovation. # Future Proofing your Company Going Cloud Native ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Ebook ## Discover how to future-proof your company with cloud-native technologies The past few years have presented numerous challenges for businesses, prompting a need for greater agility and innovation. With the rise of digital-first strategies driven by AI and ML, companies must adapt quickly to meet the increasing demand for digital offerings. To thrive in this evolving landscape, businesses need a long-term perspective on digital operations and growth. From an IT perspective, this can only be successful if you: - Increase development speed and investment - Reduce operational costs and shift resources towards innovation - Leverage automation from development to operations Explore the benefits of cloud-native transformation and learn how to calculate your ROI using Kubermatic’s tools. Transform your business today and stay ahead in the digital era. If our form couldn't load correctly – This can have multiple reasons like ad blocker, not accepted cookies, JavaScript deactivated. However, you can still get in touch with us! Simply click on the button below, and you'll be able to submit the form and reach out to us for any inquiries or assistance you need. [Open form](https://share.hsforms.com/1yb32iKY1QWWr44bXrGYgYw2piu8) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## ContainerDay Security 2024: Multi-Cluster Service Deployments With Operators and KubeCarrier - **URL:** https://www.kubermatic.com/resources/cloud-native-security-a-new-paradigm-for-a-new-world/ - **Date:** 2024-10-16 - **Description:** Discover a new security paradigm in the cloud native world in this talk at ContainerDay Security 2024. It will introduce the concepts of zero-trust security, shift-left security, and continuous security, and explain how these concepts can be applied to cloud native environments! # Cloud Native Security: A New Paradigm for a New World - CDS 2024 ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Mario Fahlandt's talk at ContainerDay Security 2024 Cloud native computing has revolutionized the way applications are developed and deployed. However, it has also introduced new security challenges. The traditional security paradigm, which is based on perimeter-based security, static security controls, and a reactive security posture, is no longer sufficient to protect cloud native environments. This talk will discuss the need for a new security paradigm in the cloud native world. It will introduce the concepts of zero-trust security, shift-left security, and continuous security, and explain how these concepts can be applied to cloud native environments. The talk will also discuss the benefits of the new security paradigm, such as improved security posture, reduced risk, and increased agility and scalability. Finally, the talk will provide some examples of organizations that have successfully implemented the new security paradigm, and discuss some emerging cloud native security technologies. **Speaker: Mario Fahlandt, Customer Delivery Architect at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Beyond the Hype: Unveiling Real-World Container Use Insights - **URL:** https://www.kubermatic.com/blog/beyond-the-hype-unveiling-real-world-container-use-insights/ - **Date:** 2026-04-30 - **Description:** Explore real-world insights on containerization, revealing both successes and lessons learned. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Julian Hansert In the fast-paced realm of modern technology, containers have emerged as a game-changer, promising seamless scalability, resource optimization, and rapid deployment. But amidst the hype surrounding containerization, what do real-world experiences reveal? **Let's delve into the insights from businesses that have embraced containers, exploring both their success stories and the valuable lessons they've learned along the way**. ## Seamless Scalability One of the most touted benefits of containers is their ability to scale effortlessly. Businesses across industries have leveraged containerization to dynamically adjust their computing resources according to demand spikes. Whether it's handling sudden surges in website traffic or managing complex data processing tasks, containers have provided the scalability needed to keep operations running smoothly without compromising performance. [The journey of our customer, Vonage](/customers/vonage/), in efficiently managing Kubernetes at scale highlights the seamless scalability containers offer. Facing challenges in delivering secure application development across diverse Kubernetes environments, Vonage turned to the Kubernetes Heavy Lifting with KKP solution. Leveraging Kubermatic Kubernetes Platform, Vonage streamlined cluster management, leading to a fully functional fleet management solution across multiple clouds using KKP. ## Resource Optimization: A Case in Point Efficiency is key in today's competitive landscape, and containers offer a solution by enabling resource optimization. By encapsulating applications and their dependencies into portable units, businesses have streamlined their infrastructure, reducing overhead costs and maximizing resource utilization. This efficient use of resources not only translates to cost savings but also enables faster innovation and development cycles. As a great example of the efficiency gained achievable through containerization can serve our [Partner Success Story with SVA](/resources/managed-kubernetes-as-a-service-in-the-bioinformatics-cloud/) where the KKP was implemented at the [Berlin Institute of Health (BIH)](https://www.bihealth.org/en/). By automating infrastructure management and providing a user-friendly interface, bioinformaticians could focus more on their research and less on cluster maintenance. This streamlined approach not only enhanced operational efficiency but also accelerated innovation in biomedical research, ultimately contributing to BIH's mission of medical translation. ## Rapid Deployment Time-to-market is critical for staying ahead of the competition, and containers have revolutionized deployment processes with their agility and speed. Businesses can package their applications once and deploy them consistently across different environments, eliminating the need for manual configuration and reducing deployment times from weeks to minutes. This accelerated deployment cycle allows organizations to respond swiftly to market changes and customer demands, gaining a competitive edge in today's dynamic landscape. [Learn how Interhyp and Kubermatic achieved a Faster Time-to-market: from 2 Days to 1 Hour.](/customers/interhyp/) **However, beyond the success stories lie valuable lessons learned by businesses navigating the complexities of container adoption** ## Infrastructure Complexity While containers offer numerous benefits, managing containerized environments can introduce complexities, especially at scale. Businesses have encountered challenges in orchestrating and managing container clusters, ensuring high availability, and implementing robust monitoring and logging solutions. Overcoming these challenges requires careful planning, automation, and investment in specialized tools and expertise. These challenges are exemplified by our recent customer, an automotive client, who faced the significant task of [scaling Kubernetes integration in their private cloud infrastructure](/customers/automotive/). The solution involved developing an integration between the private cloud infrastructure and [Kubermatic Kubernetes Platform (KKP)](/products/kubermatic-kubernetes-platform/), facilitating the direct creation of Kubernetes clusters within the cloud environment. As a result, there was a noticeable enhancement in scalability, flexibility, and performance within the cloud operations. ## Security Concerns As with any technology, security remains a top priority in containerized environments. Businesses have grappled with securing container images, implementing access controls, and ensuring compliance with regulatory requirements. Container security requires a holistic approach, **encompassing vulnerability management, runtime protection, and continuous monitoring to mitigate risks effectively**. For instance, [*running Kubernetes environments with poorly configured networks can expose vulnerabilities to unauthorized access*](/blog/container-security-what-matters/), while outdated operating systems on individual nodes can compromise entire clusters. Proactive measures include enforcing TLS, restricting Kubelet permissions, and monitoring for unauthorized connections to insecure services. Additionally, network segmentation, role-based access controls (RBAC), and regular scans for security vulnerabilities play crucial roles in maintaining a secure Kubernetes environment. ## Cultural Shift Embracing containerization often entails a cultural shift within organizations, requiring teams to adopt new processes, tools, and workflows. Businesses have faced resistance to change, siloed development practices, and the need for upskilling existing teams. Successful container adoption requires strong leadership, effective communication, and a commitment to fostering a culture of collaboration and innovation. ## Conclusion While containers offer immense potential for enhancing scalability, resource optimization, and rapid deployment, their adoption requires careful consideration of both the benefits and challenges they entail. By learning from real-world experiences and embracing best practices, businesses can harness the power of containers to drive innovation, agility, and competitiveness in today's digital landscape. --- ## Hannover Messe 2024: Safe Cobots and Swift Containers - **URL:** https://www.kubermatic.com/blog/hannover-messe-2024-safe-cobots-and-swift-containers/ - **Date:** 2026-04-30 - **Description:** Discover the latest innovations from under-the-radar companies at Hannover Messe 2024 - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Sebastian Scheele Beyond the major players that annually dominate the Hannover Messe's thematic landscape, the early days of the international industrial fair in 2024 reveal numerous exciting developments among companies that less frequently find themselves in the spotlight. Among these are technology providers for secure collaborative robotics and software companies introducing container technology into manufacturing. ## Nexcobot: Leading the Charge in Functional Safety Innovation [Nexcobot](https://www.nexcobot.com/en/index) made a grand entrance to the Hannover Messe. The expert in developing open and modular systems for intelligent robots and motion control received a crucial functional safety certification from TÜV Rheinland (IEC 61508 and ISO 13849-1). The solution "Robasafe" was developed in an international project in collaboration with Fraunhofer IWU from Chemnitz and Intel. ## Elevating Safety Standards in Manufacturing: Insights from Industry Leaders "Due to increasingly diversified market demands, manufacturing has evolved from rapid mass production to customer-specific adaptations, autonomous machines, and human-robot collaboration. Particularly in scenarios where humans and machines are jointly involved in the production process, the safety requirements of intelligent manufacturing have significantly increased. With the functional safety certification of the SCB100 safety control platform, we can make collaboration between humans and robots safer and significantly improve production efficiency," explains Jenny Shern, General Manager at Nexcobot. "Our company is committed to continuous product development in functional safety, offering companies safer and more reliable products, with which they can realize secure solutions such as Cobots and other systems. We look forward to collaborating with industry partners to establish an open ecosystem for functional safety. Nikolai Ensslen, CEO and co-founder of Synapticon GmbH, also emphasizes the security aspect in connection with collaborative robotics. "While at the Hannover Messe, many exhibitors this year focus primarily on the keyword AI or artificial intelligence in capital letters, looking behind the scenes quickly reveals that many manufacturers are mainly working on making their robots and autonomous transport systems safer. The keyword here is 'Functional Safety.' Only when this can be implemented in practice can AI be used in robotics on a large scale. I would even go so far as to say that the requirements for functional safety will increase once robot manufacturers increasingly equip their products with AI." ## Containers Marching into the OT World Containers were primarily a term known to IT (information technology) experts but are now gaining immense importance in the OT (operational technology) world. Software containers describe a technology with which companies can package and isolate software with their entire application environment—meaning all elements necessary for operation. This allows the respective software or application to be easily and fully functionally moved into individual environments. <img src="/static/kubermatic-representatives-on-hannover-messe-2024.jpg" alt="People networking at the Hannover Messe conference" width="800" height="533" loading="lazy" style="display:block;height:auto;margin:20px auto;"> <small><em>Photo Credits: #CampusOS Fraunhofer Heinrich Hertz Institute HHI</em></small> Sebastian Scheele, CEO and Co-founder of the Hamburg-based IT company Kubermatic reports a rapid increase in inquiries about container technology from companies in the manufacturing industry and mechanical engineering. Kubermatic, together with Fraunhofer HHI, is exhibiting at the Hannover Messe to demonstrate the use of container technology for the operation of 5G campus networks. "The topic of containers and Kubernetes has gained tremendous momentum in recent months and is now increasingly crossing over from classical IT into the OT sector. An example of this is Manufacturing Execution Systems (MES). These will increasingly be made available by the respective manufacturers as containers. All companies that want to use such systems must adapt to this. Likewise, we see that data exchange with PLC systems will increasingly be done via containers, which brings many advantages. We expect much more attention to this topic in the coming months in an industry under tremendous pressure for efficiency." <p style="text-align:right;"> <em>Sebastian Scheele</em><br> <em>Co-founder and CEO at <a href="/">Kubermatic</a></em> </p> --- ## VMware: The Death of An Industry Standard. Ensuring a Smooth Transition to a VMware Alternative - **URL:** https://www.kubermatic.com/blog/vmware-the-death-of-an-industry-standard/ - **Date:** 2026-04-30 - **Description:** Discover how companies are navigating the aftermath of Broadcom's VMware license termination and price hikes. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Mario Fahlandt ## Ensuring a Smooth Transition to a VMware Alternative After acquiring VMware, Broadcom terminated all licenses and only offered a continuation of the leading virtualization software to a few customers beyond April 1, 2024. At the same time, the new owner significantly raised prices. However, many companies and public institutions rely on the previously dominant virtualization software. Cloud providers, in particular, whose business models rely heavily on VMware technology, are hit hard. The Cloud Native ecosystem offers alternatives, enabling customers to leverage their existing hardware. By embracing an open-source strategy, businesses can replace significant components of the VMware infrastructure at lower costs. This blog post elucidates how companies can surmount the challenges of modernization and develop an open-source-based solution. ## How Can Companies Address the Challenges of Modernization and Build an Open-Source-Based Solution? Typical vSphere setups often exhibit a strong dependence on traditional virtual machines. This stems from the rarity of true greenfield scenarios in established enterprises. While new projects may introduce elements of a greenfield environment, they often rely on the company's existing infrastructure. Especially in enterprise IT, the primary objective is to support the business goals, with IT serving as both a cost center and an enabler. IT departments face numerous challenges, including the departure of staff who have developed critical software. This poses the risk of poorly maintained or neglected software. These factors contribute to a significant challenge for IT departments: about 70% of the IT budget is allocated to maintaining existing systems, leaving only 30% for innovation or differentiation. Therefore, the focus should shift towards striking a new balance between maintenance and innovation efforts. Strategies include reducing vendor lock-in by adopting industry-standard practices like agile methods such as DevOps or cloud technologies and minimizing or managing technical debt. To achieve this, modernizing the technology stack is essential. When infrastructure changes are necessary, it's an opportune time not only to switch hypervisors but also to reassess the strategy and modernize the application landscape. To modernize an application portfolio, there are three main strategies: ### 1. VM Migration VM migration is the simplest and fastest option. Older applications remain intact, while a new hypervisor enables new features. Often, VMs can be imported from an existing hypervisor, creating new integration points between older and newer layers. Implementing VM migration can be done with a Kubernetes management platform. The starting point is usually monolithic applications that are difficult to change without destroying functionality. Using a feature like Open Source & Enablement, integrations can be leveraged to expose data and functions with an open-source stack. Cloud Native Enablement allows activation on Kubevirt to achieve the goal of running VMs with Kubevirt alongside containers on the Kubernetes management platform. ### 2. Lift and Shift Lift & Shift moves applications more towards a cloud-native approach. Existing components are containerized, making them usable on any CaaS platform, whether on-premises or in the cloud. Retaining external integrations and data in older applications would be possible. However, these so-called legacy applications must be well-written and optimally adapted. Implementing Lift & Shift modernization with a Kubernetes management platform would look like this: From non-open-source-based middleware applications, migration to an open-source stack is facilitated through Open Source & Enablement. Cloud Native Enablement allows activation on the Kubernetes management platform, enabling applications to be modernized on API and microservices cloud architecture in the form of containers. ### 3. Complete Architecture Review and Redesign The most comprehensive option involves overhauling the existing infrastructure. Not only is the technology stack modernized, but platform-as-a-service (PaaS) and various software-as-a-service (SaaS) solutions are also leveraged to create a more resilient, easier-to-maintain, and potentially more cost-effective IT environment. ## Implementing Complete Refactoring with Kubermatic: Starting from monoliths or applications on non-open-source middleware slated for retirement, Open Source & Enablement maps the capabilities of the architecture and design of the old system onto the new architecture. With Cloud Native Enablement, practical experience with Kubermatic's modern container platform can be gained during setup and training. This enables the creation of a new suite of applications on modern cloud-native infrastructure. ## Migration to Cloud Native and Open Source It is time to regain control of one's own infrastructure. Migrating to cloud-native and open-source products is viable and offers numerous advantages for companies to leverage their existing infrastructure further. A Kubernetes management platform makes it easier to leave the Broadcom ecosystem and reshape the infrastructure with a cloud-native and open-source approach to future-proof it. **Having trouble finding the right Kubernetes solution for you?** Explore various options and pathways for VMware migration with us: [https://www.kubermatic.com/info/vmware-alternative/](/info/vmware-alternative/) --- ## Exploring Containers and Edge Computing: Navigating the Challenges and Solutions - **URL:** https://www.kubermatic.com/blog/exploring-containers-and-edge-computing/ - **Date:** 2026-04-30 - **Description:** Explore the transformative power of Edge Computing and Kubernetes. - **Categories:** Best Practices - **Tags:** Best Practices - **Authors:** Moath Qasim **Edge Computing** is revolutionizing the internet and is a hot topic in IT circles and businesses. It entails bringing computing resources and data storage closer to data sources to improve response times, save bandwidth, and unlock new business opportunities across various sectors, such as manufacturing, retail, healthcare, and telecommunications. Examples include network-dependent applications such as live interactions, augmented reality, connected cars, autonomous driving, and manufacturing. In an era where consumers and businesses demand the shortest possible time between question and answer, Edge Computing is the only way to shorten the time it takes to deliver this information. Edge Computing accelerates this timeframe by reducing latency, processing data even with limited bandwidth, cutting costs, and ensuring data sovereignty and compliance. It also poses some hurdles, but they can be overcome through tailored use of Kubernetes. ## Edge Computing is On the Rise – Companies are Turning to Kubernetes The radically new way companies can create and process data at the edge will create new markets – and is already doing so. The global Edge Computing market is expected to grow massively in the coming years. **One forecast predicts that the market volume will increase from three billion US dollars in 2020 to twelve billion US dollars in 2028**. The key question is: which operational models and technologies will be able to tap into this potential effectively? Edge Computing is still new, and established practices have yet to emerge. Even without standards in this area, many companies are turning to Kubernetes to meet these requirements. **According to the latest survey by the Cloud Native Computing Foundation (CNCF), 86 percent of companies already use the open-source system to manage container applications**. While Kubernetes was born in the cloud, its benefits extend to the rapidly emerging Edge Computing market. Given that hardware and software are distributed across hundreds or thousands of locations, the only practical way to manage these systems is through standardization and automation using cloud-native technologies. However, companies must consider the specific challenges that the Edge presents if they want to use Kubernetes to manage their Edge Computing deployments. ## Why is Edge Computing a challenge? Managing applications across multiple edge locations demands security, centralized resource management, and automated operations for resilience. Edge systems must swiftly deploy workloads, offer stability, and support workload portability. With containers, notably Kubernetes, gaining traction, managing deployments across growing clusters poses a challenge. Companies encounter challenges when integrating Edge Computing into their existing infrastructure, as it requires efficient management of diverse infrastructures across different locations. This shift from traditional data centers and cloud computing also involves deploying containers and virtual machines at the edge. ## Common Challenges in Edge Computing **Companies face three major challenges:** - **Building a consistent infrastructure to reduce snowflake-servers** - **Overcoming the issues of unstable products** - **Recruiting skilled personnel to build and maintain Edge Computing architectures.** IT executives know that automation in deploying and managing applications significantly improves stability and innovation rates while reducing costs. They have recognized that the path to achieving their Edge Computing goals lies in the cloud, but most are stuck in the proof-of-concept phase or have only implemented a handful of applications. These companies have not yet overcome the hurdle of IT automation in the Edge area. This is often because they underestimate the complexity of Edge Computing or fail to implement the necessary new operational models. Some have also failed to build expertise in cloud-native automation. **Resource constraints are often the biggest concern**. Kubernetes was developed in the cloud with nearly unlimited scaling capabilities. In contrast, Edge Computing typically has a very limited number of resources. The constraints can vary significantly, from a few servers to a few hundred MB of memory when moving from regional Edge to Device Edge. However, they all share the restriction that any additional overhead impairs the execution of the actual applications. Against this backdrop, the question now arises: **How can the footprint of Kubernetes be reduced to make more room for business applications?** ## Operationalizing Edge Computing Standardizing and automating cloud-native technologies like Kubernetes could be crucial for Edge Computing success. However, managing containers and virtual machines in a unified stack remains challenging. Solutions like KubeVirt enable seamless integration of virtual machines into Kubernetes, offering various benefits for developers and operators. Multi-cluster management is vital for Edge Computing, requiring solutions like Kubermatic to automate management across diverse infrastructures. This approach streamlines the deployment, control, and operation of Edge Computing environments, making them more efficient and productive. <img src="/static/exploring-containers-and-edge-computing-img1.jpg" alt="Kubernetes blue kubes" width="800" height="450" loading="lazy" style="display:block;height:auto;margin:20px auto;"> Edge Computing spans various locations, each with different device and bandwidth constraints levels. Each level of Edge Computing connects to and is influenced by higher-level functions, with the Edge area serving as the workload's execution space. **Kubernetes can be viewed as two parts: a central control component and a distributed processing area**. Worker Nodes execute applications, while the control plane coordinates workload installation, application lifecycle, and config management. Workloads can function without the control plane, only requiring it for updates and restarts of the worker node. This paradigm shift allows for rethinking Kubernetes cluster construction for resource-constrained environments, with Worker Nodes operating on limited resources and the Control Plane centrally located with additional resources. ## Edge Computing Requires a Cloud-Native Mindset Today You may ask: "Why Opt for Cloud-Native Solutions for the Edge?" The rationale behind adopting a cloud-native framework for edge computing primarily revolves around the need to manage expansive edge environments akin to cloud workloads effectively. By leveraging a scalable and standardized API for infrastructure management, organizations can seamlessly extend their operational capabilities to the edge, ensuring consistency, scalability, and efficiency across diverse deployment scenarios. Managing distributed computer systems isn't new to IT; it predates the internet and is fundamental to its development. However, Edge Computing introduces new challenges in scope and complexity. Beyond the multitude of locations, Edge Computing must navigate rugged environments, remote or inaccessible areas, sporadic connectivity, dynamic deployment, global data access, and security risks. These technical challenges are compounded by business considerations. Viewing the edge environment as a business entity reveals the necessity for near-zero-touch operations. <img src="/static/exploring-containers-and-edge-computing-img2.jpg" alt="The moon in the dense clouds" width="800" height="450" loading="lazy" style="display:block;height:auto;margin:20px auto;"> Cloud-native technologies, born in the cloud, hold the key to realizing Edge Computing's potential. Cloud-native principles, such as standardized infrastructure and automated processes, minimize operational effort, making Edge Computing operationally and financially feasible. ## Conclusion Edge Computing presents a paradigm shift in internet architecture, addressing the demand for rapid data processing and delivery. By leveraging Kubernetes, companies are exploring new operational models to tap into the potential of Edge Computing. Despite challenges like infrastructure standardization and resource constraints, embracing cloud-native principles can streamline deployments, making them operationally and financially viable. With a cloud-native mindset, organizations can overcome hurdles and unlock opportunities in Edge Computing, transforming internet infrastructure. --- ## From Legacy to Cloud Native - **URL:** https://www.kubermatic.com/resources/from-legacy-to-cloud-native/ - **Date:** 2024-05-22 - **Description:** Watch this webinar to explore the journey from legacy systems to cloud-native solutions. Learn how you can build a platform on your existing hardware in a cloud native way. # From Legacy to Cloud Native ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Let's explore different solutions to VMware The past months have been rough for VMware customers and users alike. The acquisition of VMware by Broadcom has prompted a profound shift on the modern IT landscape. The current world economics are also hindering modernization projects, and organizations are looking for ways to save costs. Additionally, the need to manage VM workloads and container platforms is steadily increasing. One Open Source Project in particular is emerging in the market to fulfill both of these needs. KubeVirt is a CNCF incubating project and a fast-growing alternative to VMware’s Hypervisor. It combines the abilities and possibilities to interconnect the VM World with the Container world. Join us for an insightful webinar as we explore the journey from legacy systems to cloud-native solutions. Learn how you can build a platform on your existing hardware in a cloud native way. With the benefit of Portworx to provide reliable and highly available storage, DR and backup solutions for VMs and containers, we can create a reliable state-of-the-art platform. Let’s unlock the potential of cloud-native architecture together! **Speakers: Mario Fahlandt, Customer Delivery Architect at Kubermatic; and Daniel Paul, Cloud Architect at Portworx.** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Living on the Edge: Exploring KKP Revolutionary Edge Provider - **URL:** https://www.kubermatic.com/blog/living-on-the-edge-exploring-kkp-revolutionary-edge-provider/ - **Date:** 2026-04-30 - **Description:** Discover the Future of Edge Computing with KKP's Revolutionary Edge Provider - **Categories:** Products - **Tags:** KKP - **Authors:** Moath Qasim In the ever-evolving landscape of Kubernetes, a groundbreaking addition has emerged with the latest release of [Kubermatic Kubernetes Platform (KKP) 2.25](/blog/kkp-2-25-introducing-the-ai-native-infrastructure-platform/) - the **Edge Provider**. This innovative feature redefines the integration of edge appliances into user clusters, offering a paradigm shift in edge computing. <img src="/static/kkp-2-25-edge-provider-1.png" alt="" width="800" height="256" loading="lazy" style="display:block;height:auto;"> ## What exactly is the Edge Provider, and how does it differentiate itself in the realm of Kubernetes orchestration? Imagine it as the next evolution of Kubeadm, tailored specifically to meet the unique demands of edge computing environments. Unlike traditional setups, where the control plane resides centrally, the Edge Provider decentralizes this architecture. While the control plane remains centralized within KKP, the worker nodes are dispersed geographically, positioned at the edge of the network. This decentralized approach ensures optimal performance and scalability for edge deployments. **One of the standout features of the Edge Provider is its seamless integration with Operating System Manager (OSM), allowing for streamlined configuration of edge devices**. With the ability to copy joining scripts from Machine Deployments, administrators can effortlessly onboard edge nodes to the provider's cluster, enhancing operational efficiency and reducing deployment complexities. ## Unleashing Unprecedented Flexibility and Scalability with KKP's Edge Provider The introduction of the Edge Provider marks a significant milestone in KKP's journey towards empowering organizations with cutting-edge Kubernetes capabilities. By enabling users to establish the control plane within KKP and seamlessly add machine deployments, KKP offers unparalleled flexibility and scalability in managing edge computing environments. The generation of comprehensive scripts further simplifies the deployment process, ensuring a smooth transition to edge computing architectures. ## Edge infrastructure management simplified As organizations continue to embrace edge computing to meet the demands of modern applications and IoT deployments, KKP's Edge Provider emerges as a game-changer in simplifying edge infrastructure management. With its robust features and intuitive functionality, KKP 2.25 sets a new standard for edge computing orchestration, empowering organizations to thrive on the edge of innovation. ## Conclusion In a rapidly evolving technological landscape, the introduction of KKP 2.25's Edge Provider represents a monumental leap forward in edge computing integration within Kubernetes environments. Edge Provider represents a significant advancement in edge computing orchestration, offering organizations unparalleled flexibility andAs the demand for edge computing continues to grow. It emerges as a vital tool in simplifying infrastructure management, setting a new benchmark for innovation and efficiency on the edge. Visit our [Documentation](https://docs.kubermatic.com/kubermatic/v2.25/architecture/supported-providers/edge/) for more hands-on information. --- ## Streamlining Automotive Cloud Operations: Enhancing Private Cloud Infrastructure - **URL:** https://www.kubermatic.com/customers/automotive/ - **Date:** 2026-06-23 - **Description:** Discover how a leading automotive company tackled the challenge of scaling Kubernetes integration within their private cloud infrastructure. # Streamlining Automotive Cloud Operations: Enhancing Private Cloud Infrastructure ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## The Challenge ### Scaling Kubernetes Integration in Private Cloud Infrastructure Our automotive client faced a significant challenge: integrating Kubernetes at scale into their existing infrastructure, which was based on a private cloud setup. They aimed to leverage this infrastructure to seamlessly create Kubernetes clusters, enabling various departments and teams to collaborate without being isolated while maintaining multi-tenancy and cost-effectiveness. Additionally, they sought to replace expensive VM hypervisors with [more efficient alternative](/info/vmware-alternative/), all while streamlining operations and implementing Kubernetes as a service. This required a comprehensive solution capable of automating VM provisioning and Kubernetes cluster creation on demand, addressing their specific requirements for scalability, flexibility, and cost optimization. ## The Solution ### Enabling Kubernetes Clusters as a Service in Private Cloud Infrastructure The solution involved developing an integration between the private cloud infrastructure and Kubermatic Kubernetes Platform (KKP), facilitating the direct creation of Kubernetes clusters within the cloud environment. This integration was realized by implementing a new provider within the machine controller component of KKP. With this setup, the machine controller could provision virtual machines (VMs) within their private cloud and configure them to operate as Kubernetes clusters. This transformation effectively turned the private cloud into a platform capable of offering Kubernetes clusters as a service (KAS), providing users with a streamlined solution for managing their Kubernetes workloads. Similar to managed Kubernetes services offered by leading cloud providers, this solution enabled the creation of managed Kubernetes clusters within the private cloud infrastructure, empowered by the functionalities of the KKP platform. Through the KKP API, users could initiate the provisioning process, facilitating the seamless creation of Kubernetes clusters within the private cloud environment. ## The Impact ### Seamless Integration and Enhanced Cloud Offerings The integration of the solution into their platform has been successful, operating seamlessly within their infrastructure and enabling efficient management of software and production lines. Looking ahead, the next steps involve expanding its deployment across a greater number of machines, including bare metal. Additionally, consideration is being given to implementing a load balancer as a service feature using [Kubermatic KubeLB](/products/kubelb/) Solution. Ultimately, the primary objective is to provide Kubernetes as a service as part of the cloud offering, aligning with broader goals for enhancing the platform’s capabilities. ![Red lines abstract image](/static/red-lines-abstract-image.jpg) ## Automotive The integration of KKP into the private cloud infrastructure enabled significant advancements in streamlining operations and improving cloud offerings. KKP’s capabilities facilitated the automation of Kubernetes cluster creation, enabling seamless workload management. This integration optimized operational efficiency, ensured multi-tenancy, and promoted cost-effectiveness. As a result, there was a noticeable enhancement in scalability, flexibility, and performance within the cloud operations. --- ## Container Security - What Matters - **URL:** https://www.kubermatic.com/blog/container-security-what-matters/ - **Date:** 2026-04-30 - **Description:** Navigate through practical advice on minimizing attack surfaces, securing Kubernetes API, and implementing robust security controls. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Marko Mudrinić Container environments under Kubernetes are generally considered secure, yet effective security still requires attention. Burning or lost containers in rough seas are among the unwanted but not unrealistic scenarios in maritime freight shipping. Therefore, safety is paramount in seafaring. Improved cargo monitoring and increasingly precise weather forecasts make container shipping safer. The same applies to containers in IT - as a new way of deploying and managing applications, but also bringing specific security requirements. Overall, containerization offers some advantages for security. However, **it is crucial to consider the considerable complexity and potential security vulnerabilities of containers**. Based on this, suitable measures can be taken to ensure effective security. ## The Benefits of Containers: Concept and Reality The benefits of containers are conceptually rooted in isolation, portability, monitoring, and automation. However, containers with typically highly distributed environments and large clusters, can also pose security risks. Regular updates are important to keep containers at a high-security level. Clusters running on an end-of-life version must be avoided. Poor network configuration can also make Kubernetes environments vulnerable to unauthorized access. Already, individual nodes with outdated operating systems or a targeted denial-of-service attack can endanger several or even all deployed machines. Since containers are frequently started and stopped, monitoring them is not straightforward. Firewalls, standard in conventional IT environments, are not suitable for container domains. The lack of effective container isolation opens up pathways for attackers to compromise sensitive data, processes, or access privileges. However, the most common security issues when deploying a Kubernetes instance are easily avoidable. ## Key Functions of a Kubernetes Security Tool Proactive vulnerability management can significantly reduce the risk of security breaches. A possible attack path in the production environment is the code. To protect it, policies such as enforcing TLS, restriction of Kubelet permissions, blocking unused ports, and regular scans and tests are proven effective. Digital signatures ensure that the code is trustworthy. A corresponding tool should also make configuration problems visible beyond the code. Part of security management is also to prevent incoming and outgoing data connections to insecure services. A security risk is running the applications from untrusted registries, as this can facilitate malware attacks or unauthorized access through backdoors. Therefore, it is advisable to minimize the attack surface and restrict potential attack vectors. This also means avoiding unnecessary packages, libraries, and shells in development, limiting permissions to the minimum necessary, and loading "secrets" only for specific tasks. Applications in the cluster should be isolated, with resources and teams separated by namespaces. Network segmentation can prevent lateral movement within a cluster. This should be done before production, as Kubernetes' default network settings do not restrict communication. Incoming and outgoing connections should be precisely defined and routed through policies. Similarly, access should be restricted through namespaces and meticulously configured role-based access controls (RBAC). The Kubernetes API is the centerpiece of the entire system, through which all internal and external clients connect and communicate with Kubernetes. The Kubernetes API Server and other Kubernetes components can have vulnerabilities and pose attack surfaces during runtime. In the worst-case scenario, compromised containers must be isolated quickly and replaced with "clean" containers while the attack is analyzed and stopped. ## Trust is good, control is better In general, it is advisable to keep the Kubernetes environment lean and to scan operating systems, images, and all external sources thoroughly for security vulnerabilities. For external sources, it is always a case of: Trust is good, control is better. Therefore, it is also necessary to limit privileges to a minimum and never run application processes as root. A read-only root filesystem prevents attacks based on software installation or filesystem changes. Integrated image scans and security tests in the CI/CD pipeline complement the security package. Administrators must also ensure that only authorized, compliant images enter the environment to limit the risk of running containers with vulnerable or malicious code. Images from dubious sources are risky, so only approved images should enter the CI/CD pipeline. Risk management is supplemented by integrated control mechanisms in Kubernetes. For example, the security context can be configured to restrict pod access. Proactive monitoring is crucial to keep track of process activities, all services, and external communication. **The use of a comprehensively automated platform for deploying and managing clusters is advisable to operate a container environment under Kubernetes securely - even in rough seas.** --- ## Vonage's Journey to Efficiently Managing Kubernetes at Scale - **URL:** https://www.kubermatic.com/customers/vonage/ - **Date:** 2026-06-23 - **Description:** Explore Vonage's journey in efficiently managing Kubernetes at scale, leveraging Kubermatic Kubernetes Platform for streamlined cluster management. # Vonage’s Journey to Efficiently Managing Kubernetes at Scale ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## The Challenge ### Building a hardened security baseline for containerized applications based on Kubernetes Vonage faced a significant challenge in Kubernetes management, particularly in establishing a hardened security baseline for containerized applications across diverse Kubernetes environments. The absence of a consistent security framework led to inefficient Kubernetes management at scale, causing delays and hindering rapid progress due to the need for continual relearning and reworking of Kubernetes implementation processes. ## The Solution ### Kubernetes Management Simplified with KKP To overcome these challenges, Vonage turned to the Kubermatic Kubernetes Platform (KKP) for streamlined Kubernetes management. Built on Kubernetes, KKP provided the necessary extensibility and ease of cluster management through its operator functionality and Cluster API. This solution enabled seamless scaling and upgrades across Kubernetes environments with minimal effort. Additionally, the supportive KKP community played a crucial role in enhancing Vonage’s Kubernetes management practices, reducing the operational burden and simplifying maintenance. ## The Impact ### Scalable Kubernetes Management Across Multiple Clouds Today, Vonage has successfully implemented a fully functional fleet management solution across multiple clouds, powered by KKP. This robust Kubernetes management solution has been further enhanced with custom extensions that support additional platform engineering tasks. Vonage is now expanding its product offerings, including a unified database and cross-cluster solutions, all built on KKP’s Kubernetes management capabilities. These advancements ensure continuous improvement, allowing Vonage to integrate advanced features and maintain efficient Kubernetes management at scale. ![Abstract image](/static/abstract-image.jpg) ![Vonage white logo](/static/vonage-white-logo.svg) [Vonage](https://www.vonage.com/), a global cloud communications leader, helps businesses accelerate their digital transformation. Leveraging the Vonage platform, their fully programmable unified communications and contact center applications enable companies to transform how they communicate and operate from the office or anywhere, providing enormous flexibility and ensuring business continuity. > At Vonage, we accelerate the world's ability to connect with one unified cloud communications platform. Scalable, secure, and reliable real time communications require a digital backbone that can live up to that. With Kubermatic Kubernetes Platform, we currently operate hundreds of nodes and will rocket this number to five thousand this year. All reliable, all secure, all open source. Eddie Wassef, Vonage ![Eddie Wassef](/static/Eddie-Wassef.png) --- ## Will ARM be the new Mainstream in our Data Centers? - **URL:** https://www.kubermatic.com/resources/will-arm-be-the-new-mainstream-in-our-data-centers/ - **Date:** 2024-04-03 - **Description:** Watch this talk to get insights on the current state of the ecosystem, open source and cloud native landscape. Let's find out if it is possible to create out of the results a real future business case for ARM based revolution in Data Centers. # Will ARM be the new Mainstream in our Data Centers? ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Tobias Schnek's talk at CloudNative Rejekts EU 2024 As I have been working with my new Apple Mac M1 for over a year, I was wondering why ARM is not used more in regular application workload scenarios? ARM for desktop computing is really stable, seamless, reliable and for me a game changer - when will we recognize the same for our servers? Especially in times when energy and raw materials are expensive, we should also benefit from the efficiency of ARM technology in our Data Centers. So what’s missing? We have Kubernetes on ARM, we have the main operating systems supporting ARM, we have a lot of application software and programming languages supporting ARM out of the box, why don’t we use this potential in large scale? Join the talk to get more insights on the current state of the ecosystem, open source and cloud native landscape. Let’s find out if it is possible to create out of the results a real future business case for ARM based revolution in our Data Centers. Similar to ARM for the desktop, ARM for cloud native workload could be a game changer and make operation of our workload more efficient and cheaper. The big hyperscalers such as AWS, Google, Azure already have ARM based machines available in their data centers. We already see huge potential for ARM in edge devices in IOT use cases, but also at classical on-premise or edge data centers. Running future application stacks in a most efficient way will save energy. Lower energy usage, with fewer devices for hosting the same amount of machines, means also lower costs. That efficiency makes it attractive for everyone, including on-premise data centers. The talk will show what is already possible and where there are limitations in the CNCF ecosystem. A live demo will show differences during build- and run-time on a characteristic application stack for enterprise workload. The audience will see if the technology has a real chance to be the “next thing” at their datacenter by using cloud native technologies. **Speaker: Tobias Schneck, Principial Architect at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Why Kubernetes is Inappropriate for Platforms and How to Make it Better - **URL:** https://www.kubermatic.com/resources/why-kubernetes-is-inappropriate-for-platforms-and-how-to-make-it-better/ - **Date:** 2024-04-03 - **Description:** This talk is about extending Kube, adapting its architecture to be a better fit for a world where instead of container orchestration two new personas are at the center. # Why Kubernetes is Inappropriate for Platforms and How to Make it Better ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Sebastian Scheele, Stefan Schimanski and Mangirdas Judeikis' talk at KubeCon + CloudNativeCon EU 2024 The ecosystem is building platforms on Kubernetes now, starting with a hub cluster and then sticking tools for Gitops, for application descriptions and for infrastructure management together, with the goal to create custom APIs for the platform consumers. This works, but hits limits of Kube as a framework quickly. Can we do better? Oh yes, we can! This talk is about extending Kube, adapting its architecture to be a better fit for a world where instead of container orchestration two new personas are at the center: (a) the service & API provider (b) the self-service consumer, often developers or application owners. We focus on 3 dimensions to enable Kube to serve platform engineering better: - from kcp we take the workspace hiararchy as a vastly better multi-tenancy primitive. - cross-workspace API exports and bindings tailor-made for the service provider and consumer personas. - cluster mounting that integrates Kube clusters for a unified user interface and identity management. **Speakers: Sebastian Scheele, Co-Founder & CEO at Kubermatic with Stefan Schimanski (Upbound) & Mangirdas Judeikis (CAST AI)** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Kubernetes-style APIS for SaaS-like Control Planes with kcp - **URL:** https://www.kubermatic.com/resources/kubernetes-style-apis-for-saas-like-control-planes-with-kcp/ - **Date:** 2024-04-03 - **Description:** Explore the core concepts that kcp adds to the Kubernetes API and discover how kcp could be the right fit for your next platform based on cloud native technologies. # Kubernetes-style APIS for SaaS-like Control Planes with kcp ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Marvin Beckers and Mangirdas Judeikis' talk at Project Lightning Talks at KubeCon + CloudNativeCon EU 2024 Kubernetes is all about orchestrating container workloads. But to orchestrate workloads at the scale that Kubernetes is used for, you need a solid API. Thankfully, the community built amazing technology to power the Kubernetes API, and a thriving ecosystem has since evolved around it. kcp is a CNCF Sandbox project that harnesses all the API building blocks of Kubernetes and moves them past workload orchestration. We are building a control plane to host any kind of API in a SaaS-like fashion, all powered by Kubernetes API concepts and rules. As a Kubernetes downstream project, kcp does not try to reinvent the wheel but to extend the Kubernetes APIs with stronger multitenancy, API management and global scalability capabilities. Join us in exploring the core concepts that kcp adds to the Kubernetes API and discover how kcp could be the right fit for your next platform based on cloud native technologies. **Speakers: Marvin Beckers, Team Lead at Kubermatic with Mangirdas Judeikis (CAST AI)** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## A practical guide to SIG Release Tooling for Kubernetes Subprojects - **URL:** https://www.kubermatic.com/resources/practical-guide-to-sig-release-tooling-for-kubernetes-subprojects/ - **Date:** 2024-04-03 - **Description:** This session provides a great reference for many years for all Kubernetes subprojects on how they can make their release processes more efficient and aligned with the Kubernetes release process. # A practical guide to SIG Release Tooling for Kubernetes Subprojects ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Marko Mudrinić's talk at Kubernetes Contributor Summit EU 2024 SIG Release invested many years into creating tooling for publishing different types of artifacts. There are also other supporting tools such as release-notes for generating changelogs, bom for generating SBOMs, and more! All those tools are actively used when publishing Kubernetes releases, but the Kubernetes subprojects are often not aware of tools that SIG Release offers and maintains. In this session, Marko will shed some light on those tools focusing on how you can publish container images, binary artifacts, and system (Debian and RPM) packages. The session will cover the most important processes around the Kubernetes image registry (registry.k8s.io) such as image promotion, what’s OpenBuildService and how you can use it to publish system packages to pkgs.k8s.io, and finally where you can find information and support for all the tools that we offer. This session will provide a great reference for many years for all Kubernetes subprojects on how they can make their release processes more efficient and aligned with the Kubernetes release process. **Speaker: Marko Mudrinić, Software Engineer at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Platform Engineering Day: Building a Platform Engineering API Layer with kcp - **URL:** https://www.kubermatic.com/resources/building-a-platform-engineering-api-layer-with-kcp/ - **Date:** 2024-10-16 - **Description:** This talk discusses how kcp supercharges platform engineering with a global control plane for all internal services. # Building a Platform Engineering API Layer with kcp - Platform Engineering Day ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Marvin Beckers' talk at Platform Engineering Day EU 2024 Self-service is a central aspect of platform engineering, and platform engineering teams frequently build on top of Kubernetes to utilise its amazing API design. The kcp project has been accepted into the CNCF Sandbox in 2023 and extends Kubernetes API concepts beyond container orchestration. This talk will discuss how kcp supercharges platform engineering with a global control plane for all internal services. As a central API layer, kcp enables a SaaS-like experience between internal service providers and developers, transforming internal developer platforms into a service marketplace. All via concepts and tools that developers working with Kubernetes already know and love. kcp expands the world of platform engineering beyond the limits of single Kubernetes clusters, and therefore transforms the scale at which platform teams and internal service providers can operate. This talk will explore patterns for both service providers and developers and how kcp makes their lives easier. **Speaker: Marvin Beckers, Team Lead at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Unleashing Kubernetes Intelligence - running k8sgpt utilizing your own fine-tuned LLM - **URL:** https://www.kubermatic.com/resources/unleashing-kubernetes-intelligence-running-k8sgpt-utilizing-your-own-fine-tuned-llm/ - **Date:** 2024-04-03 - **Description:** Follow Mario in this session, creating your own fine-tuning of an LLM with Kubeflow and taking LocalAI for a spin inside our cluster to use this very model as a base. # Unleashing Kubernetes Intelligence - running k8sgpt utilizing your own fine-tuned LLM ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Mario Fahlandt's talk at Cloud Native AI Day EU 2024 K8sGPT is a fast rising star inside the CNCF landscape. Most of us use it currently with paid resources - because of this, some of us can’t utilize its powers. Follow me into the rabbit hole, creating your own fine-tuning of an LLM with Kubeflow and taking LocalAI for a spin inside our cluster to use this very model as a base. Now we have a local interface to use for k8sgpt. So we can scan our Kubernetes clusters, diagnosing and triaging issues in simple English. K8sgpt helps to pull out the most relevant information and enrich it with AI. As a benefit on top we enrich the LLM in the fine-tuning process with our own project or Open Source Documentation. So LocalAI acts as our very own ChatGPT to ask for help in our environment. The most amazing thing, we can do everything inside of Kubernetes, in our own infrastructure in our own Datacenter or Private Cloud. **Speaker: Mario Fahlandt, Customer Delivery Architect at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## KKP 2.25 - Introducing the AI-Native Infrastructure Platform - **URL:** https://www.kubermatic.com/blog/kkp-2-25-introducing-the-ai-native-infrastructure-platform/ - **Date:** 2026-04-30 - **Description:** Check out the latest update of KKP 2.25, featuring a multitude of enhancements, including AI-driven infrastructure operations and automated Kubernetes backups and recovery. - **Categories:** Products - **Tags:** KKP - **Authors:** Csenger Szabo We are thrilled to announce the latest update on **Kubermatic Kubernetes Platform (KKP) 2.25**! In this release, we're introducing a vast range of exciting features and enhancements designed to streamline your Kubernetes operations and enhance your cloud-native journey. From leveraging the power of AI for Infrastructure Operation to automated Kubernetes backups and recovery and much more. KKP 2.25 is packed with innovative solutions that will take your Kubernetes and infrastructure operation experience to the next level. Let's dive in and explore what's new! ## Leverage the power of AI for Infrastructure Operation Maximize the value of every operation with the AI-Native Infrastructure Platform, specifically designed to utilize AIOps to ensure optimal operator and end-user experiences. Leveraging AI for the operation of your infrastructure or constructing an infrastructure optimized for AI, Kubermatic offers the flexibility, automation, and confidence required for simplified operations, increased efficiency, and dependable performance at scale. In KKP 2.25, K8sGPT has been integrated to KKP as a default application and also to the web terminal feature as a CLI tool. Leverage the power of Artificial Intelligence and GenAI within KKP from now! K8sGPT brings you the next level of cluster debugging, with the help of AI all debugging sessions will be brought closer to the human language and understanding. Additionally the NVIDIA GPU Operator is included in KKP 2.25. This cutting-edge addition empowers you to harness the full potential of specialized hardware resources seamlessly within your Kubernetes environment. Say goodbye to the hassle of manually configuring multiple software components. With KKP and the NVIDIA GPU Operator, you can effortlessly manage nodes equipped with NVIDIA GPUs and other specialized devices through Kubernetes' device plugin framework. ## Automated Kubernetes backups Kubermatic Kubernetes Platform 2.25 revolutionizes the way you manage Kubernetes clusters and persistent volumes, ensuring seamless backup, recovery, and migration across both on-premises and public cloud environments. Unlike the current backup integration that directly accesses the Kubernetes etcd database for backups and restores for platform admin. The new backup solution, powered by Velero under the hood, leverages the Kubernetes API to saves the volumes and snapshots to a custom storage destination, what’s more, now Project owners in KKP are able to manage all the backup related settings, so the whole operation can be detached from the platform administrator. This new backup feature is ideal for disaster recovery and can also be used for migrating your Kubernetes clusters. It also enables Project owners to only backup and restore specific namespaces of the clusters. To eliminate monotonous manual work, regular backups and the deletion of old backups can be fully automated. ## KubeLB - Load Balancing as a Service KubeLB is brand-new a Kubermatic product that we have just launched! It enables you to load balance traffic across your Kubenertes-fleet in both cloud and on-premise environments. KKP’s Enterprise Edition has also been integrated with KubeLB in order to leverage the benefit of this multi-tenant load balancing solution on your existing KKP environment instantly. You can find more information on our [product page](/products/kubelb/). ## Edge Provider <img src="/static/kkp-2-25-edge-provider-1.png" alt="" width="800" height="256" loading="lazy" style="display:block;height:auto;"> A new provider has been added to KKP for edge appliances, and this new Edge provider revolutionizes how these devices are being integrated to user clusters. Think of it as an evolution of Kubeadm, but with enhanced capabilities designed for the unique demands of edge computing. What sets this provider apart is its ability to not only facilitate the joining of edge devices to clusters, but also the possibility to configure the machines by Operating System Manager (OSM). <img src="/static/kkp-2-25-edge-provider-2.png" alt="" width="800" height="131" loading="lazy" style="display:block;height:auto;"> As a unique feature for Edge providers, the joining script can be copied from a Machine Deployment in order to be able to bring them to the Edge provider’s cluster nodes. ## Commenting in application definitions to help application deployment As a platform administrator, you can add comments to your application definitions living in the Application Catalog to make application deployment easier for your tenants and User Cluster owners. ## KubeVirt in the Application Catalog KubeVirt revolutionizes Kubernetes environments by seamlessly incorporating traditional virtual machine workloads alongside containerized applications, offering versatility in modern cloud-native architectures. And now, KubeVirt is now part of the KKP Application Catalog, which means even easier deployment of KubeVirt clusters. ## Fully upgraded MLA stack components User cluster Monitoring Logging Alerting components have been updated in order to improve features and performance of the overall KKP MLA stack.This update includes upgrading the Cortex, Grafana, Loki and MinIO components of the MLA to their newer versions to make sure that you can use all available functions of them. ## Supporting Kubernetes 1.29 and GCP CCM KKP 2.25 now supports Kubernetes 1.29, and since it removed in-tree providers, we also added support for Google Cloud Provider's Cloud Controller Manager. Therefore, Kubernetes 1.26 reached its end of life, so 1.26 is not going to be an actively supported version anymore. ## Enabling Cilium Ingress in the clusters We introduced an easy option to enable an ingress for Cilium in the user clusters. Deploying an application most likely requires an ingress later on, so creating one on the UI during cluster creation makes things more straightforward. ## Using upstream Helm chart for kube-state-metrics By adding the upstream Helm chart of kube-state-metrics, now you can enable custom Kubernetes resources, and [custom resource metrics](https://github.com/kubernetes/kube-state-metrics/blob/main/docs/customresourcestate-metrics.md) can be fully configured. ## Improvements for Flatcar There are several improvements around Flatcar in this release, such as: - We added Flatcar as supported Operating System for Google Cloud Engine - Configuring static networking for machine deployments. The implementation is generic, however we only support static networking for flatcar at the moment - Flatcar can be used with VMWare Cloud director ## Improvements for VMware Cloud Director ### vCloud Director CSI driver in the seed cluster CSI controller of VMware Cloud Director now lives in the user cluster namespace in the seed cluster which avoids that CSI drivers propagate the cloud credentials to the user clusters. This change improves the overall security of the KKP installation. ### Multi availability zone support for VMware Cloud Director From now on, user cluster VMs in VMware Cloud Director can be stretched out across multiple data centers in order to achieve a multi-AZ setup. We added support for attaching multiple networks to vApps. This enables better failover support and even higher availability, which HA setups will benefit from, because in several cases they require multiple availability zones. ### Support for IP allocation modes in VCloud Director We are introducing support for limiting IP Allocation modes for VMware Cloud Director. This is helpful when either POOL or DHCP are unavailable or not the ideal solutions for IP address allocation; admin can limit which mode to allow. ## Summary As we wrap up this journey through KKP 2.25, it's evident that the Kubermatic team is committed to deliver cutting-edge solutions that empower your cloud-native endeavors. From disaster recovery with Velero to harnessing the power of AI with K8sGPT, and a multitude of other enhancements, KKP continues to evolve to meet the dynamic needs of modern Kubernetes environments. We're excited to see how these features will empower your Kubernetes operations and look forward to accompanying you on your cloud-native journey. Stay tuned for future updates and don't hesitate to reach out with any questions or suggestions via [Contact Us](/contact-us/) form. --- ## Navigating Company Growth: Top 7 Challenges - **URL:** https://www.kubermatic.com/blog/navigating-company-growth-top-7-challenges/ - **Date:** 2026-04-30 - **Description:** Learn about optimizing cash flow, empowering your team, staying competitive, and more! - **Categories:** Company - **Tags:** Announcements - **Authors:** Julian Hansert In the fast-paced world of business, seeing your company grow quickly can be really exciting. But as your company gets bigger, you'll face lots of challenges, like figuring out how to **handle more work, dealing with complexities such as employee management, evolving company rules** and keeping the things that made your company great in the first place. How can you overcome these challenges while still sticking to what's important to you and making sure your products or services stay really good? Let's talk about some ways to do that. ## 1. Understanding Your Competition As your company expands, you're likely to venture into new markets and engage with fresh customer segments, inevitably drawing the attention of new competitors. While competition is inherent in business, your growth strategy should encompass tactics to retain existing clients and attract new ones, irrespective of your rivals' maneuvers. In navigating this landscape, conducting **a competitor analysis is essential**. By subscribing to their newsletters, examining open documentation, and testing their website forms, you gain insights that help refine your strategies. Remember, in this competitive arena, we're all in the same boat. **It's about learning from each other while staying focused on our strengths and meeting customer needs**. ## 2. Employees Management & Empowerment The key is streamlining processes to get both staff and clients in alignment. Your team is your greatest asset, especially during periods of rapid growth. Empower them with the resources, training, and support they need to excel in their roles. Now [Kubermatic](/) manages 45+ employees in 14 different countries. Of course, a larger, more diverse workforce brings with it more challenges, and requires effective leadership, communication, and organizational skills. **Encourage a culture of innovation and collaboration where everyone feels valued and heard**. For example, consider implementing regular skill development workshops, mentorship programs, regular **Lunch & Learn meetings**, and access to online learning platforms to enhance their skills. By investing in your team, you're not only ensuring their success but the success of your company as a whole. Here at Kubermatic we Invest in hiring processes that prioritize alignment with our company values. We provide regular training and development opportunities for our employees. Having in place **clear performance evaluation frameworks, regular revision of KPIs** wrapped up in the **weekly one-on-one Feedback Talks as well as daily stand ups** inside each company's department, we collect and offer detailed feedback that is critical for facilitating employee progression. ## 3. Lack of Time & Learning to Delegate In today's fast-paced business environment, time is often a precious commodity. One of the most common challenges faced is the struggle to balance an ever-growing workload with limited time. **Learning to delegate tasks effectively becomes crucial in such scenarios**. Delegation not only frees up time for more strategic activities but also empowers team members, fostering a culture of trust and collaboration. By delegating, leaders can focus on high-priority tasks, while also providing growth opportunities for their team members. If you fear losing control, one best practice for you could be: start with smaller, not-so-high-impact tasks and observe the results. Alternatively, ask open strategy questions and see how the employee would handle the situation. ## 4. Keeping Up With Market Transformation **The business landscape is constantly evolving, and your company must be agile and adaptive to navigate growth challenges successfully**. Embrace a mindset of continuous improvement and be willing to pivot when necessary. Stay attuned to market trends, customer feedback, and industry developments, and be prepared to adjust your strategies accordingly. For instance, utilizing tools such as **daily news alerts, collaborating with analysts like Gartner for comprehensive market insights**, and keeping an eye on industry interviews can provide valuable perspectives. Additionally, conducting regular market research and competitor analysis can help your company maintain a competitive edge and respond effectively to changing market dynamics. ## 5. Scaling Up Company Culture As your company grows, **maintaining a strong company culture becomes increasingly important**. Cultivate a culture that fosters creativity, collaboration, and accountability. Celebrate successes, learn from failures, and ensure every team member feels valued and connected to the company's mission and vision. For example, organize team-building activities, recognition programs, and company-wide town hall meetings to foster a sense of belonging and shared purpose. Additionally, implementing such best practices as creating a **comprehensive company handbook**, creating Slack channels for casual conversations and bonding, establishing a buddy system for new hires, and maintaining transparency regarding company goals and strategies are instrumental in nurturing a thriving company culture. ## 6. Cash Flow is KING **Great Opportunities + Fast Growth = Bigger Decisions**. The more rapid growth the company experiences, the more frequently it encounters cash flow problems and it happens with greater severity compared to slower-growing companies. Ensuring a healthy cash flow is vital for sustaining and growing your business, especially during periods of rapid expansion. - One way to manage cash flows more effectively is by **implementing a detailed cash flow forecasting system like [Agicap](https://agicap.com/it/lp/software-pianificazione-finanziaria/)**, which we rely on here at Kubermatic. This involves regularly monitoring your incoming and outgoing cash to anticipate potential shortfalls or surpluses. - In addition to establishing clear payment terms with clients and vendors to improve cash flow, it's crucial to consider the **trade-offs between multi-year upfront payments and monthly payments**. Multi-year upfront payments provide an immediate influx of cash, and may lower the effort initially for collecting the money. They also can result in lower total contract value (TCV), may require higher effort to build up the trust beforehand, but potentially lower risk of churn. On the other hand, monthly payments offer greater flexibility for both sides, but may require higher effort for collecting money and could result in a slower buildup of cash reserves. Balancing these trade-offs is essential for optimizing cash flow management. - In addition to establishing a cash reserve fund serving to provide a buffer for unexpected expenses or revenue fluctuations, **it's crucial to determine the optimal run rate considering the current macroeconomic situation**. With factors like war, inflation, and shifts in VC behavior, frugality reigns supreme. ## 7. Staying True to Your Core Values As your company expands, it's easy to lose sight of the principles that guided you from the beginning. **However, staying true to your core values is paramount to maintaining your company's identity amidst growth**. Make sure your values are not just words on a wall but ingrained in every aspect of your operations. Regularly revisit and reinforce them with your team to ensure alignment. ## Conclusion Navigating company growth challenges requires a strategic approach that balances expansion with maintaining quality and core values. By staying true to your principles, focusing on quality, empowering your team, embracing scalable solutions, staying agile, cultivating a strong company culture, and seeking guidance when needed, you can successfully navigate the journey of growth while ensuring the long-term success of your company. --- ## KubeLB Unveiled: New Multi-Tenant Load Balancer - **URL:** https://www.kubermatic.com/blog/introducing-kubelb/ - **Date:** 2026-04-30 - **Description:** Transforming Microservices Application Delivery with Cutting-Edge Cloud-Native Multi-Tenant Load Balancing - **Categories:** Company - **Tags:** KubeLB, Announcements - **Authors:** Sebastian Scheele ## Transforming Application Delivery with Cutting-Edge Cloud-Native<span class="br"></span> Multi-Tenant Load Balancing As applications transition from monolithic architectures to cloud-native-based, the need for advanced load balancing solutions becomes paramount. Current Application Delivery Controllers (ADCs) often struggle to keep pace with the evolving complexities of cloud-native-based applications. ## Evolution of Load Balancing Architectures ### Monolithic Architecture The traditional monolithic architecture, while suitable for smaller applications, becomes unwieldy and impractical for larger and more complex applications. Scaling, deploying changes, and adopting new Kuberntes clusters and teams become cumbersome, limiting flexibility and innovation. ### Cloud-Native Load Balancing Architecture Cloud-Native Load Balancing offers a solution by decomposing the load balancer structure into smaller, independent load balancers. Each load balancer aligns with a specific business function, enabling rapid development, independent deployment, and efficient scaling. KubeLB embraces the multi-tenant paradigm to provide a scalable and responsive load balancing solution. ### The Rise of Kubernetes API and Scaling Strategies The adoption of Kubernetes API and Cloud Controller Manager (CCM) for configuring the load balancer played a pivotal role in the success of using load balancers with Kubernetes. KubeLB leverages CCM for lightweight communication between clusters and the control plane, enhancing flexibility and efficiency. The platform employs various scaling strategies, multi-tenant isolation, ensuring optimal resource utilization, isolation and application responsiveness. ## What is KubeLB? KubeLB, a project by Kubermatic, is a Kubernetes native tool that centrally manages load balancers for Kubernetes clusters across multi-cloud and on-premise environments. It addresses the absence of multi-tenant, multi-clustered load balancer implementation in Kubernetes by providing a centralized solution for load balancer management. Load balancer operates as a service, so you can have multiple customers using the same software. It detects the customer environment and acts accordingly. KubeLB aims to overcome limitations in load balancing for bare-metal Kubernetes environments by offering a centralized management solution. It fills the gap left by in-tree or out-of-tree cloud provider implementations, ensuring load balancing for services of type LoadBalancer in any environment. ### Architecture KubeLB comprises two components: - CCM (Consumer Cluster Manager): Deployed in consumer clusters, CCM propagates load balancer configurations to the manager based on changes in Kubernetes services and nodes. - Manager: The central component receives load balancer configurations from CCM(s) and deploys and configures load balancers accordingly. It relies on the envoy proxy for traffic load balancing and supports three deployment topologies: Dedicated, Shared (default), and Global. <img src="/static/kubelb-chart.png" alt="stacked containers image" width="500" height="500" loading="lazy" style="display:block;height:auto;margin:20px auto;"> ## KubeLB - Designed for Hundreds of Teams and Apps ### Distributed Architecture KubeLB utilizes an architecture based on software-defined networking (SDN) principles. This architecture separates the data plane from the control plane, enabling seamless scaling of application delivery services within and across data centers and cloud locations while maintaining centralized control. ### Multi-Tenant Driven Application Delivery KubeLB's distributed load balancers, powered by high-performance Cilium and Envoy, provide comprehensive application delivery services. The platform's multi-tenant approach allows strong separation of access and traffic, enabling automatic scaling to handle increasing demand for dynamic multi-clusters and multi-teams. ### Elastic Scale and Application Affinity KubeLB's elastic data plane allows for real-time scaling across multiple tenants and applications. Cilium and Envoy ensure application affinity, placing them in proximity for optimal performance while avoiding network tromboning. ### Dataplane Isolation for Tenants and Applications To prevent interference between critical applications, KubeLB allocates dedicated micro load balancers for each tenant, ensuring true multi-tenant application services without the "noisy neighbor" problem. ### Programmability and N-Way Active Redundancy KubeLB emphasizes programmability through native Kubernetes APIs, enabling seamless integration with tools like kubectl, Crossplane, Terraform, and Ansible. The platform ensures N-Way Active-Active redundancy for high availability. ## Conclusion KubeLB provides an elastically scalable load balancer with a distributed data plane, spanning various on-premise and cloud locations. Its distributed architecture and elastic scaling at the load balancer level significantly enhances application performance. The clean separation of planes reduces operational complexity, making KubeLB an ideal solution for integrating, operating, and managing ADC appliances across diverse locations. All in, KubeLB is highly flexible, cost focused, scalable and efficient. <style type="text/css"> .btn-ctas { display: flex; margin-top: 32px; margin-bottom: 32px; } .btn-ctas .btn { color: #262626; background-color: transparent; font-weight: 400; } .btn-ctas .btn:hover { color: #fff; background-color: #00d9d2; } </style> <div class="btn-ctas"> <a href="https://docs.kubermatic.com/kubelb/" class="btn" target="_blank">Read Documentation</a> </div> --- ## Kubermatic KubeLB - Multi-Tenant Load Balancer - **URL:** https://www.kubermatic.com/products/kubelb/ - **Date:** 2026-05-07 - **Description:** Enter cloud-native multi-tenant load balancing solution designed to address the operational challenges inherent in this new era of application development. # Kubermatic KubeLB Experience unprecedented scalability and efficiency with Kubermatic KubeLB, your ultimate Load Balancer solution. Tailored for multi-tenant service providers, Kubermatic KubeLB operates seamlessly as a service, allowing multiple customers to leverage the same software with ease. [Get your free demo](/demo/) [Whitepaper](/whitepaper-kubelb-cloud-native-multi-tenant-load-balancer/) [Documentation](https://docs.kubermatic.com/kubelb/latest/release-notes/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) **Welcome to Kubermatic KubeLB, the next-generation application delivery platform designed for cloud-native architectures. As cloud-native have evolved, Kubermatic KubeLB offers a multi-tenancy approach to load balancing, providing seamless scalability, security, and management for distributed applications and teams.** ## Evolution of Cloud-Native Load Balancer Architectures ### Monolithic Architecture Challenges - Limited separation for multi-cluster, multi-team applications - Difficult to adopt new technologies without network team involvement - Inefficient scaling of individual load balancer across many clusters - Complex, risky, and time-consuming deployments ### Cloud-Native Architecture Benefits - Rapid development and evolution of multi-tenant load balancer services - Streamlined operation of hundreds of load balancers - Independent deployment of services - Efficient scaling of individual load balancers - Utilization of Kubernetes APIs for lightweight communication - Enhanced application scalability across teams and Kubernetes clusters ## Rise of REST and Kubermatic KubeLB for Microservices Apps #### Kubermatic KubeLB Overview Kubermatic KubeLB is a software-based application delivery and load balancer platform, providing secure, scalable network services for cloud-native applications. Its distributed architecture, powered by high-performance Cilium and Envoy, offers unparalleled flexibility and scalability. Kubermatic KubeLB introduces significant enhancements including support for **Layer 7 Application load balancing through Ingress and Gateway API** for advanced traffic management, **automated DNS and certificate management** for security and **automated tenant registration**. Additionally, it features the new SyncSecrets API for secure, flexible management of sensitive data alongside various other improvements and features. These upgrades streamline operations and boost performance, making Kubermatic KubeLB ideal for modern data center needs. ![Kubermatic KubeLB diagram](/static/kubelb-chart_hu_9a321f60a3a61637.png) ![Kubermatic KubeLB full diagram](/static/kubermatic-kubelb-scheme_hu_610bccedd5230522.png) ## Key Features ![](/static/icons/refresh-icon.svg) ### Layer 4 Load Balancing Centralized Layer 4 (TCP and UDP) Load Balancing: Provision, manage, and secure Layer 4 load balancers across traditional, hybrid, and multi-cloud environments from a single, unified control plane. ![](/static/struct-grad-icon.svg) ### TCP/UDP Both TCP and UDP load balancers are supported along with advanced configuration support using TCPRoute and UDPRoute from Gateway API. ![](/static/shield-icon.svg) ### Web Application Firewall Centralized WAF protection across your multi-tenant, multi-cloud fleet. Block SQL injection, XSS, and OWASP threats without any application changes. ![](/static/icons/community-icon.svg) ### Management Dashboard Centralized management dashboard for your load balancing fleet. Monitor health, performance, and security across all your load balancers and tenants from a single pane of glass. ![](/static/icons/refresh-icon.svg) ### Ingress to Gateway API Migrator Automated migration from Ingress to Gateway API resources. Convert your existing ingress-nginx resources to Gateway API resources without any manual changes. ![](/static/icons/community-icon.svg) ### Agent to Agent & MCP Gateway Kubermatic KubeLB provides support to connect, secure, and observe agent-to-agent and agent-to-tools communication using [agentgateway](https://agentgateway.dev/). Routing to Model Context Protocol (MCP) servers is also supported. ![](/static/icons/dumbbell-icon.svg) ### Ingress Ingress support for Layer 7 Application Load Balancing ![](/static/icons/network-icon.svg) ### Gateway API Extensive Gateway API support for Application Load Balancing. Including policy-based routing, circuit breaking, rate limiting, and more. ![](/static/exchange-icon.svg) ### BGP Kubermatic KubeLB can be used with any load balancing appliance. Route advertisement protocols such as BGP, OSPF, and L2 are all supported. ![](/images/icons/visuals/item16.svg) ### Airgap & Offline Support Kubermatic KubeLB can be deployed in airgapped and offline environments, providing secure and scalable load balancing without requiring external connectivity. ![](/static/sheets-icon-blue.svg) ### TLS Automation to manage and provision certificates from a single control plane ![](/static/cycle-grad-icon.svg) ### DNS Automation DNS automation for workloads distributed among a fleet of clusters ![](/static/icons/thumb-up-icon.svg) ### Dual-stack and IPv6 only Support Kubermatic KubeLB supports IPv4, IPv6, and dual-stack load balancing. ![](/static/icons/paper-plane-icon.svg) ### Traffic Management Advanced traffic management features like circuit breaking, rate limiting, failover, timeouts, retry policies and much more to ensure application resilience and quality of service ![](/images/icons/magnify-user-icon.svg) ### Centralized Security & Authentication Manage security including mTLS, JWT-based access control, OIDC integration, and API key authorization for all your tenants from a central point, ensuring uniformity across your environment. ![](/static/icons/user-gear-icon.svg) ### Multi-tenant Environment Each tenant is isolated at namespace and network level, enabling higher segregation and preventing noisy neighbor issues. ![](/static/rocket-grad-icon.svg) ### No Vendor Lock-in for LoadBalancing appliance Kubermatic KubeLB can be used with any cloud-based, third-party, or bare metal load-balancer appliance or implementation. ![](/static/icons/robot-icon.svg) ### AI Gateway Kubermatic KubeLB offers centralized AI Gateway support using [Agentgateway](https://agentgateway.dev/), supporting advanced features such as: - AI Gateway to support and secure LLM consumption - Inference Gateway support to intelligently route to AI workloads - Prompt Enrichment and guardrails ## Why KubeLB? ![](/static/gear-icon.svg) ### Application Delivery and Load Balancing Comprehensive Layer 4 and Layer 7 load balancing with full Gateway API support. Extensible and scalable, built for modern cloud-native environments. ![](/images/icons/admin-icon.svg) ### Reduce Operational Complexity and Cost One control plane for hundreds of load balancers. Automate tenant registration, DNS management, and certificate provisioning, eliminating manual configuration across your fleet of clusters. ![](/images/icons/shaking-hands.svg) ### Centralized Security and Governance Enforce security policies uniformly across clusters with true multi-tenant isolation. Centralized Web Application Firewall, OIDC Authentication, Access Control, and more. ![](/images/icons/multicloud.svg) ### Environment Agnostic and Multi-Cloud Ready Deploy anywhere; public cloud, private cloud, or bare metal. Flexible architecture with no vendor lock-in for your load balancing infrastructure. ![](/static/centralized-grad-icon.svg) ### Scalable Multi-Tenant Architecture Strong tenant isolation with automated registration. Elastic scaling across multi-clusters and multi-teams with multiple gateways per tenant for flexibility and redundancy. ![](/static/cycle-grad-icon.svg) ### Built for High Availability N-Way Active-Active redundancy ensures your applications stay online. Automatic scaling based on traffic patterns for consistent performance under load. [Contact Sales](/contact-sales/) ## Community vs. Enterprise: Feature Breakdown | Feature | Enterprise Edition | Community Edition | |-------------------------------------------------|----------------------------------------------------|------------------------------------------------------------| | **Load Balancing** | | | | TCP/UDP Load Balancing | ![available](/static/check-mark-icon.svg)available | ![available](/static/check-mark-icon.svg)available | | Ingress | ![available](/static/check-mark-icon.svg)available | ![available](/static/check-mark-icon.svg)available | | **Gateway API** | | | | HTTPRoute, GRPCRoute | ![available](/static/check-mark-icon.svg)available | ![available](/static/check-mark-icon.svg)available | | TCPRoute, UDPRoute, TLSRoute | ![available](/static/check-mark-icon.svg)available | ![not available](/static/cross-mark-icon.svg)not available | | Multiple Gateways per tenant | ![available](/static/check-mark-icon.svg)available | ![not available](/static/cross-mark-icon.svg)not available | | Traffic Policies (Client/Backend) | ![available](/static/check-mark-icon.svg)available | ![not available](/static/cross-mark-icon.svg)not available | | **Security** | | | | Web Application Firewall (Beta) | ![available](/static/check-mark-icon.svg)available | ![not available](/static/cross-mark-icon.svg)not available | | Airgap & Offline Support | ![available](/static/check-mark-icon.svg)available | ![not available](/static/cross-mark-icon.svg)not available | | Stronger tenant isolation with network policies | ![available](/static/check-mark-icon.svg)available | ![not available](/static/cross-mark-icon.svg)not available | | **Management** | | | | Ingress to Gateway API Migration (Beta) | ![available](/static/check-mark-icon.svg)available | ![available](/static/check-mark-icon.svg)available | | Bring your own certificates | ![available](/static/check-mark-icon.svg)available | ![available](/static/check-mark-icon.svg)available | | DNS automation | ![available](/static/check-mark-icon.svg)available | ![not available](/static/cross-mark-icon.svg)not available | | Certificate management | ![available](/static/check-mark-icon.svg)available | ![not available](/static/cross-mark-icon.svg)not available | | Gateway/LoadBalancer limits | ![available](/static/check-mark-icon.svg)available | ![not available](/static/cross-mark-icon.svg)not available | | Load Balancing Policies | ![available](/static/check-mark-icon.svg)available | ![not available](/static/cross-mark-icon.svg)not available | | CLI tunneling | ![available](/static/check-mark-icon.svg)available | ![not available](/static/cross-mark-icon.svg)not available | | **Observability** | | | | Prometheus metrics | ![available](/static/check-mark-icon.svg)available | ![available](/static/check-mark-icon.svg)available | | Grafana dashboards | ![available](/static/check-mark-icon.svg)available | ![available](/static/check-mark-icon.svg)available | | **Supply Chain Security** | | | | Artifact signing (Cosign) | ![available](/static/check-mark-icon.svg)available | ![available](/static/check-mark-icon.svg)available | | SBOMs | ![available](/static/check-mark-icon.svg)available | ![available](/static/check-mark-icon.svg)available | | Vulnerability scanning | ![available](/static/check-mark-icon.svg)available | ![available](/static/check-mark-icon.svg)available | > Kubermatic KubeLB has revolutionized our application delivery, seamlessly aligning with the evolution to microservices, providing unparalleled scalability, security, and management while simplifying operational complexities and proving to be an ideal solution for our modern data center requirements. Giovanni Coppa, Wobcom. [Get your free demo](/demo/) --- ## KubeLB: Cloud-Native Multi-Tenant Load Balancer - **URL:** https://www.kubermatic.com/whitepaper-kubelb-cloud-native-multi-tenant-load-balancer/ - **Date:** 2026-05-07 - **Description:** Discover how KubeLB's distributed microservices architecture dramatically reduces operational complexity of multi-tenant load balancing in cloud-native environments. # Cloud-Native Multi-Tenant Load Balancing How KubeLB Transforms Application Delivery for Modern Microservices Architectures ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Introduction Throughout the years, application architecture has evolved from client-server to service-oriented to cloud-native microservices-based architectures. This evolution significantly impacts application development methods and approaches to scalability, security, and, most importantly, application delivery. Unfortunately, the industry’s current state of Application Delivery Controllers (ADCs), also known as load balancers, falls short. The demand for services has evolved, and what once required just one service now necessitates multiple distinct services. In this new era of service explosion, it will be challenging for IT teams to effectively handle the lifecycle management of applications unless the modern-day ADC is “microservices aware” and has the appropriate automation — enabled via APIs, automation, and orchestration frameworks — to provision, configure, and manage every microservice. This paper describes how application architectures have evolved and how KubeLB’s distributed microservices approach can dramatically reduce the operational impact of microservices-based application architecture. ![](/static/kubelb-whitepaper-1.png) ## The Monolithic Architecture At the inception of web application development, the predominant enterprise application architecture involved bundling all the application server-side components into a single unit. Numerous enterprise applications, for instance, often consist of solitary WAR or EAR files. Consider developing an online store that accepts orders, verifies inventory and available credit, and handles shipments. This application comprises various components, including the front-end UI responsible for the user interface, and services dedicated to managing the product catalog, processing orders, and handling accounts. The services utilize a shared domain model, including Product, Order, and Customer. Despite its logically modular design, the application is deployed as a monolith — a single WAR file running on a web container like Tomcat. ![](/static/kubelb-whitepaper-2.png) ### Simple to Develop IDEs and development tools are oriented toward building a single application. Testing and deploying them is straightforward since everything coexists within a single application. ### Works for Small Apps The monolithic approach works well for relatively small applications with limited team sizes and modest scaling requirements. ### Becomes Cumbersome When dealing with complex applications, the monolithic architecture becomes cumbersome, posing serious challenges for scaling, experimentation, and technology evolution. Attempting a new infrastructure framework often requires rewriting the entire application, which becomes risky and impractical. To deploy new changes to one application component, you have to build and deploy the entire monolith — complex, risky, and time-consuming. In cases where one service demands significant memory resources and another is CPU-intensive, provisioning the server necessitates allocating sufficient capacity to accommodate the baseline load for every service, making cost escalation inevitable. ## The Cloud-Native Microservices Architecture The cloud-native microservices-based architecture is designed to address the issues seen with monolithic architecture. Services are disassembled into distinct services and deployed independently on separate hosts. Each microservice is dedicated to a specific business function, solely encompassing the operations essential to that particular business function. This architecture utilizes tools like Kubernetes, ArgoCD, Flux, and other cloud-native projects. ### Enhanced Developer Productivity Each service is relatively small, with a more understandable codebase for developers. This enhances developer productivity since teams are now only focused on a subset of the application; the IDE is more efficient, and running and testing the application is less time-consuming. ### Independent Deployment Since each service is isolable and not dependent on other services, developers can work on specific services in isolation without being dependent on different teams or silos within an organization. This makes continuous development, testing, and deployment easy and greatly effective. ### Granular Scaling The biggest advantage of this architecture is the ability to configure scaling, underlying hardware, and resource requirements (CPU, GPU, or memory intensive) per service. This can greatly enhance the throughput of applications while reducing the cost incurred. ![](/static/kubelb-whitepaper-3.png) ## Scaling Microservices along X, Y & Z Axes ![](/static/kubelb-circle-icon.svg) ### X-Axis Scaling Horizontal scaling involves running multiple copies of the entire application behind a load balancer. Each instance of the application is referred to as a horizontal slice. This is the most common form of scaling for web applications. ![](/static/kubelb-wheel-icon.svg) ### Y-Axis Scaling Vertical scaling involves splitting the application into different parts, each running on a separate machine — the most common form of scaling for microservices, enabling independent resource allocation per service. ![](/static/kubelb-cloud-icon.svg) ### Z-Axis Scaling Also known as functional decomposition, Z-axis scaling involves splitting the application into different parts based on data partitioning, with each part running on a separate machine. The most common representation of this is the “Scale Cube,” a three-dimensional scalability model popularized by *The Art of Scalability*. ![](/static/kubelb-whitepaper-4.png) ## Rise of Containerization and Orchestration Tools As microservices became more prevalent, tools like Docker, Docker Swarm, and Kubernetes emerged to simplify deployment and scaling. Docker revolutionized containerization, enabling consistent environments across development and production. Kubernetes advanced these capabilities, offering robust orchestration, management, and scalability for complex, distributed microservices architectures. Its powerful features — such as automated scaling, self-healing, and rolling updates — addressed many challenges associated with deploying and managing microservices at scale, making it the de facto platform for microservices in the industry. ## Challenges with Kubernetes While Kubernetes significantly simplifies the orchestration and management of containerized applications, it introduces challenges — particularly in multi-cluster and multi-tenant environments. ![](/static/icons/network-icon.svg) ### Limited Native Load Balancing Kubernetes provides interfaces for Layer 4 and Layer 7 load balancing in the form of Services and Ingresses. However, they offer limited capabilities and depend on the cloud provider or ingress provider to implement them. This creates dependency on the provider for advanced features like traffic splitting, traffic shaping, and observability. ![](/static/struct-grad-icon.svg) ### Multi-Cluster Complexity Managing network traffic, ensuring application security, and maintaining high performance across different clusters and clouds can be complex and resource-intensive. Traditional load balancers often struggle to keep up with the dynamic nature of microservices, leading to inefficiencies and increased operational overhead. ![](/static/icons/user-gear-icon.svg) ### Multi-Tenant Gaps As applications grow in complexity and scale, mission-critical workloads necessitate multi-cluster deployments. Organizations deploying multiple Kubernetes clusters across regions, availability zones, and cloud providers face new challenges: managing various clusters, ensuring consistent policies, and providing seamless communication between applications. Kubernetes doesn't natively possess these capabilities and requires additional tools. ## Introducing KubeLB KubeLB is a software-based next-generation application delivery platform with integrated analytics, which provides secure, reliable, and scalable network services for cloud-native applications. **At the heart of KubeLB is a revolutionary architecture based on SDN principles, separating the data plane from the control plane — an industry first for Application Delivery Controllers and Load Balancers.** KubeLB enables seamless scaling of application delivery services within and across data centers and cloud locations while maintaining a single point of management and control. The load balancer operates as a service, so multiple tenants can leverage the same software. It detects the tenant environment and acts accordingly. ![KubeLB scaling diagram](/static/kubelb-chart.png) ## Distributed Architecture The distributed load balancers implemented by high-performance Cilium and Envoy provide comprehensive application delivery services such as load balancing, application acceleration, and application security. Cilium and Envoy can be co-located with applications within and across cloud locations and tuned for higher performance. ![](/static/kubelb-whitepaper-5.png) ![](/static/kubelb-bulb-icon.svg) ### Placement Intelligence Using KubeLB's rich data, control, and management plane services, Cilium and Envoy can be placed close to the application's microservices and tuned for higher performance and faster client responses. ![](/static/cycle-grad-icon.svg) ### End-to-End Analytics The integrated data collectors gather end-to-end timing, metrics, and logs for each user-to-application transaction, providing actionable insights about end-user experience, application performance, infrastructure utilization, and anomalous behavior. ![](/static/rocket-grad-icon.svg) ### Elastic Data Plane KubeLB's unique distributed architecture allows Service Engines to scale automatically without human intervention, meeting real-time requirements of microservice-based applications across hundreds of tenants and thousands of applications. ## Key Capabilities ### Analytics-Driven Application Delivery KubeLB engines constantly monitor the traffic patterns of each microservice application. When a customizable threshold is met, the newly scaled-out Cilium and Envoy handle the increasing traffic load seamlessly. Furthermore, the Inline Analytics engine can send a trigger based on ambient loads to scale up or down the backend microservices applications. ### Elastic Scale The Elastic data plane of KubeLB can dynamically scale out and scale in to meet the real-time requirements of microservice-based applications across 100s of tenants and 1000s of applications. Cilium and Envoy allow network services for each microservice to be individually scaled up or down. Whether microservices are inside a single physical server, in different servers in a single data center, or even across different data centers, Cilium and Envoy automatically discover and locate themselves in the closest possible proximity to each microservice. ![](/static/kubelb-whitepaper-6.png) ![](/static/kubelb-whitepaper-7.png) ### Dataplane Isolation for Tenants and Applications To avoid sharing appliances between critical applications, tenants and applications are allocated their own Service Engine for data plane isolation. This eliminates the “noisy neighbor” problem wherein a rogue microservice tenant could potentially impact the performance of an adjacent application. KubeLB’s per-tenant, dedicated micro load balancers deliver true multi-tenant application services. ![](/static/kubelb-whitepaper-8.png) ### Programmability All interactions with the KubeLB Controller are through native Kubernetes APIs, which enable native integration with kubectl. DevOps automation tools like Crossplane, Terraform, or Ansible are also natively supported. ![](/static/kubelb-whitepaper-9.png) ### N-Way Active Redundancy Using redundancy principles from web-scale datacenters, KubeLB provides N-Way Active-Active redundancy along with Active-Active and Active-Standby availability options, ensuring your applications remain available under any failure scenario. ![](/static/kubelb-whitepaper-10.png) ## How Load Balancers Need to Evolve ![](/static/kubelb-whitepaper-11.png) Each group of Cilium and Envoy can be associated with a specific tenant. In a multi-tenant environment, traffic for a particular application is isolated to that tenant's group. KubeLB can manage multiple groups of Cilium and Envoys, with Kubernetes's role-based access control mechanism ensuring users logged into a particular tenant can only view the details of that particular tenant. 1 ### True Control/Data Plane Separation There needs to be a complete and true separation of control and data plane within the ADC, with the ability to distribute data plane resources dynamically across different hardware platforms and public/private clouds — exactly how application microservices can be distributed. 2 ### Data Plane Independence for Multi-Tenancy Achieving data plane independence (isolation) to enable multi-tenancy, especially in cloud environments. This aligns with how microservices can operate and be changed independently of each other without disrupting other microservices — the “no noisy neighbor” impact. 3 ### Application Affinity ADCs must achieve the “application affinity” concept — where resources are aligned for specific functions. This approach offers two significant advantages: the microservice enhances application response time by colocating the ADC resource alongside, and this tight alignment enables ADC resources to achieve automatic microservices lifecycle management without manual intervention, significantly reducing management complexity. 4 ### Self-Service SDN Programmability Fulfilling the self-service programmability and efficiency promise of SDN. Only through true control/data plane separation and the complete centralization of control functions can the ADC achieve the real promise of SDN — enabling one-to-one communications between its controller and the application’s control elements through RESTful APIs. ## Summary **The architecture of how applications are developed today has evolved from purpose-built monolithic code to a tightly federated collection of modular and reusable microservices. The move to microservice-app development means existing assumptions around traffic patterns, load balancing scale, and service requirements are no longer valid.** **KubeLB is an elastically scalable load balancer with a distributed data plane that can span, serve, and scale with apps across various on-premises and cloud locations. The distributed data plane empowers tenants to obtain application affinity at the microservice level, significantly enhancing overall application performance. The clean separation of planes also enables the creation of a unified, centralized control plane that significantly alleviates operational complexity associated with integrating, operating, and managing each ADC appliance across locations individually.** **In summary, KubeLB is a highly flexible, cost-focused, scalable, and efficient load balancer — particularly suited to multi-tenant service providers.** ![Global network connectivity](/static/kubelb-wp-img-2.jpg) ## Case Study: Evolving with Application Architecture In the early stages, a company focused predominantly on low complexity and overhead, leading to rapid software development. The need to rush to market implies developers typically do not have the luxury of designing the application for scalability, high availability, and redundancy. With KubeLB ADC, high availability and scalability can be quickly achieved by running the application on a pair of web servers behind a pair of load balancers — keeping operation costs to a minimum. ### Stage 1: Launch Deploy on a pair of web and database servers behind KubeLB ADC. High availability and scalability achieved immediately with minimal operational cost. ### Stage 2: Growth As demand for the business grows, scale quickly by adding more resources (X-axis scaling) behind KubeLB ADC. Static content management challenges are mitigated using caching engines on the KubeLB ADC. ### Stage 3: Scale As popularity grows, rearchitect the application into smaller services/functions. Database partitions evolve along geographical locations. With KubeLB's future-proof, security-focused design, the ADC used on day 1 can still be used as traffic grows. One instance of KubeLB can serve applications located in a data center and in the cloud simultaneously, with its centralized control and management interface making it all manageable. ## About Kubermatic Kubermatic is a leader in Kubernetes and cloud-native technologies, dedicated to empowering organizations with advanced solutions that simplify and optimize IT management. Our products are designed to meet the needs of modern enterprises, providing the tools and support necessary to drive innovation and achieve business success. For more information about KubeLB and other Kubermatic solutions, please visit our website or contact our sales team. [Get Your Free Demo](/demo/) [KubeLB Product Page](/products/kubelb/) [KubeLB Documentation](https://docs.kubermatic.com/kubelb/latest/) --- ## Must-Attend Talks | KubeCon Europe 2024 - **URL:** https://www.kubermatic.com/blog/discover-the-must-attend-kubermatic-talks-at-kubecon-europe-2024/ - **Date:** 2026-04-30 - **Description:** Explore the can't-miss Kubermatic sessions at KubeCon EU 2024, covering cloud-native topics such as AI, platform engineering, SIG release tooling, and more! - **Categories:** Company, Best Practices - **Tags:** Announcements, Kubernetes Salut, Kubernauts! 🥐 With the enchanting KubeCon Europe just around the Seine bend, the Kubermatic team is eagerly preparing for a rendezvous in the City of Lights. We've curated a lineup of five talks that promise to ignite your curiosity and deepen your understanding of cutting-edge technologies within the Kubernetes ecosystem. ## KubeCon 2024: What's New? At [KubeCon + CloudNativeCon Europe 2024](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/) in Paris, attendees can expect an immersive experience delving into the latest advancements in cloud native technologies. The finalized schedule boasts a diverse array of topics ranging from AI to WebAssembly (WASM), eBPF, and environmental sustainability. With 223 sessions, keynotes, lightning talks, and breakout sessions, as well as 90 CNCF project maintainer-hosted sessions, participants have ample opportunities to explore cutting-edge concepts and gain insights from industry experts. ## Kubermatic Talks: Mark Your Calendars With an impressive array of talks, KubeCon EU offers a diverse range of insights. Here are eight talks from [Kubermatic](/kubecon-cloudnativecon-paris/) that we are excited about: [Will ARM be the new Mainstream in our Data Centers? - Tobias Schneck, Principal Architect at Kubermatic](https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-paris-2024/talk/N7MTPK/) March 17, 04:00 PM CET at Cloud Native Rejekts Gain insights into the current state of the ecosystem and explore the potential of ARM technology in revolutionizing data centers, shedding light on its stability, reliability, and efficiency. [Unleashing Kubernetes Intelligence - running k8sgpt utilizing your own fine-tuned LLM - Mario Fahlandt - Customer Delivery Architect at Kubermatic
](https://colocatedeventseu2024.sched.com/event/1ZmKw) March 19, 10:45 AM CET at Cloud Native AI Day Mario will take you on a journey into the realm of K8sGPT, showcasing its transformative powers in Kubernetes environments. Learn how to fine-tune an LLM (Language Model) with Kubeflow and harness LocalAI within Kubernetes clusters to diagnose and triage issues using simple English. [Building a Platform Engineering API Layer with kcp - Marvin Beckers, Team Lead at Kubermatic
](https://colocatedeventseu2024.sched.com/event/1YFfY/building-a-platform-engineering-api-layer-with-kcp-marvin-beckers-kubermatic-gmbh) March 19, 11:05 AM CET at Platform Engineering Day Marvin will discuss how the kcp project supercharges platform engineering, enabling a SaaS-like experience for internal service providers and developers. Don't miss out on exploring the future of platform engineering with kcp. [A Practical Guide to SIG Release Tooling for Kubernetes Subprojects - Marko Mudrinić, Software Engineer at Kubermatic](https://kcseu2024.sched.com/event/1aOqU) March 19, 11:45 AM CET at Kubernetes Contributor Summit Join Marko as he reveals the hidden gems of SIG Release tooling, offering insights into publishing container images, binary artifacts, and system packages. Discover best practices for aligning Kubernetes subprojects with the Kubernetes release process to improve efficiency and maintain consistency. [Managing Content Streams in SIG-Contribex-Comms - Mario Fahlandt, Customer Delivery Architect at Kubermatic with Kaslin Fields (Google)](https://kcseu2024.sched.com/event/1aOq0) March 19, 01:45 PM CET at Kubernetes Contributor Summit Dive into the world of end user communications as the Contributor Comms subproject of SIG ContribEx takes on additional responsibilities this year. This interactive session welcomes all interested Kubernauts to collaborate on planning strategies for communicating with end users across diverse platforms. [Get Your CI Jobs Optimized Together! - Marko Mudrinić, Software Engineer, and Koray Oksay, Kubernetes Consultant & Instructor at Kubermatic](https://kcseu2024.sched.com/event/1aOqL) March 19, 03:00 PM CET at Kubernetes Contributor Summit Discover how to optimize CI jobs running on Prow build clusters, ensuring efficient resource usage and cost savings without compromising job stability. Learn about available tooling and receive expert guidance to optimize your jobs effectively. [Why Kubernetes is Inappropriate for Platforms, and How to Make it Better - Sebastian Scheele, CEO of Kubermatic with Stefan Schimanski (Upbound) and Mangirdas Judeikis (Cast AI)
](https://kccnceu2024.sched.com/event/1YePC) March 21, 03:25 PM CET at KubeCon + CloudNativeCon Explore the challenges of building platforms on Kubernetes and discover strategies to extend Kubernetes' architecture for improved platform engineering. Gain insights into adapting Kubernetes to better serve the needs of service providers and consumers. [Contribfest: Build, Document, and Learn About Tinkerbell Community
Templates and Integrations - Moath Qasim, Head of Engineering at Kubermatic with Jacob Weinstock (AWS)](https://kccnceu2024.sched.com/event/1Yhf5) March 22, 04:00 PM CET at KubeCon + CloudNativeCon Contribute to building and documenting community templates and integrations for Tinkerbell, collaborating with fellow community members to enhance the ecosystem's capabilities. ## Join Us at KubeCon Europe! The Kubermatic team is excited to be a part of KubeCon EU 2024. Don't miss this opportunity to engage with our team and explore the possibilities of cloud-native technologies. Be sure to mark your calendars and check the schedule for these insightful talks. We look forward to seeing you in Paris! À bientôt! For more information [visit our page](/kubecon-cloudnativecon-paris/). --- ## Building a Resilient Company Culture in Remote Setting - **URL:** https://www.kubermatic.com/blog/building-a-resilient-company-culture-in-remote-setting/ - **Date:** 2026-04-30 - **Description:** Discover how Kubermatic fosters resilience and inclusivity in remote work settings. - **Categories:** Company - **Tags:** Announcements - **Authors:** Julian Hansert As the world of work continues to evolve, remote work has become increasingly prevalent, bringing both opportunities and challenges for organizations. One of the key challenges faced by businesses in this new landscape is maintaining a strong and resilient company culture. In this thought leadership blog post, we will explore strategies implemented by [Kubermatic](/) for fostering resilience and inclusivity in remote work settings, with a focus on effective communication and connection. ## Emphasize Clear Communication Communication lies at the heart of a resilient company culture, especially in remote work environments where face-to-face interaction is limited. To foster transparency and alignment, organizations should prioritize clear and frequent communication channels. This includes **regular team meetings, one-on-one check-ins, and transparent sharing of information through digital platforms**. With the integration of HubSpot into Slack, companies can effortlessly monitor activities, milestones, celebrate accomplishments, and share insights in real-time. ## Embracing Challenges and Celebrating Victories **At Kubermatic, our TownHall meetings are more than gatherings—they're opportunities to cultivate openness and growth. We cherish the tradition of sharing war stories, where team members discuss challenges faced and lessons learned**. This fosters transparency and encourages embracing setbacks as learning experiences, strengthening our collective knowledge. Additionally, TownHall serves as a meeting for celebrating wins, fostering unity and accomplishment among our team. ## Cultivate a Sense of Belonging In remote work settings, it's essential to create opportunities for employees to connect and build relationships with their colleagues. Virtual team-building activities, such as online workshops, virtual coffee breaks, or shared interest groups, can help foster a sense of belonging among remote teams. **At Kubermatic we have a dedicated Slack channel where we virtually meet and mingle discussing some not work related topics. It is a memes kingdom**. Additionally, celebrating achievements and milestones, whether personal or professional, helps reinforce a positive company culture and encourages collaboration across remote teams. If there is a possibility, it is great to also organize company offsite gatherings from time to time. ## Lunch & Learn Kubermatic encourages its employees to participate in the Lunch & Learn initiative by incorporating **Power Hours**, dedicated blocks of time during lunch breaks where employees can exchange and delve deeper into specific topics of interest or industry trends.Through these gatherings, team members are provided with valuable opportunities to expand their knowledge base, share ideas, and enhance their skills. ## Prioritize Employee Well-being Remote work can blur the boundaries between work and personal life, leading to potential burnout and disengagement. To mitigate these risks, organizations should prioritize employee well-being by promoting work-life balance and providing resources for mental health support. Encouraging breaks, offering flexible work hours, and implementing wellness initiatives such as **virtual yoga** or **Book Clubs** as we do at Kubermatic demonstrate a commitment to supporting employees' holistic well-being, fostering a resilient workforce that feels valued and supported. ## Lead by Example Effective leadership plays a crucial role in shaping company culture, especially in remote work environments. Leaders should lead by example by demonstrating empathy, transparency, and resilience in their own actions and communications. By embodying the values of the organization and prioritizing the well-being of their teams, leaders can inspire trust and confidence, creating a positive work environment where employees feel empowered and motivated to contribute their best. ## Conclusion In the face of remote work's unique challenges, building a resilient company culture is more important than ever. By prioritizing clear communication, fostering a sense of belonging, prioritizing employee well-being, and leading by example, organizations can create an inclusive and supportive work environment where employees thrive. Wanna join our team? Check out our [Careers Page](/company/careers/) for Open Positions. --- ## The Transition of Kubernetes' Core Infrastructure to Multicloud within the CNCF - **URL:** https://www.kubermatic.com/customers/cncf/ - **Date:** 2026-06-23 - **Description:** CNCF Swift Multicloud Migration: Accelerating the Transition of Kubernetes' Core Infrastructure # CNCF Swift Multicloud Migration: Accelerating the Transition of Kubernetes’ Core Infrastructure ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## The Challenge ### Spread the Kubernetes Project Infrastructure to Multicloud The Cloud Native Computing Foundation (CNCF) serves as an open-source software foundation dedicated to advancing the adoption of cloud-native computing. Within CNCF’s extensive catalog, Kubernetes stands out as one of its major projects, operating a substantial infrastructure independently. Multiple companies contribute infrastructure resources to support activities such as builds, tests, and hosting images and packages. For open-source project developers, the ethos of resource sharing is particularly crucial, especially in maintaining aspects like infrastructure. In 2023, the imperative arose to extend the existing infrastructure beyond Google Cloud, encompassing AWS. This expansion aimed to distribute resources efficiently, optimize the allocated budget on Google Cloud, and leverage the AWS sponsorship to sustain the project’s operations. ## The Solution ### Get Community Members and Experts in time Confronted with this time-sensitive situation, CNCF turned to Kubermatic, a renowned member of the CNCF and the leading contributor to the Kubernetes Project in Europe. In early January 2023, Kubermatic’s engineers, already integral members of the Kubernetes Community, dedicated themselves full-time to assist in the endeavor. Their focus was on designing and implementing a cross-cloud solution for the Kubernetes Project. ## The Impact ### Rapid Progress on Cloud Native Transformation In Time Migration to keep the Kubernetes Project in Budget. Thanks to the swift onboarding of Kubermatic Engineers into the project, the team could efficiently address multiple migrations simultaneously, collaborating closely with the sig-k8s-infra community. ![The image of the clouds](/static/clouds-image.jpg) ![Cloud Native Computing Foundation white logo](/static/cncf-white-logo.svg) The Cloud Native Computing Foundation (CNCF) is an open source software foundation that promotes the adoption of cloud-native computing. The CNCF, a subsidiary of the Linux Foundation created in 2015, aims to establish a vendor-agnostic community of developers, end users, and IT technology and service providers to collaborate on Open Source projects. > CNCF faced a pivotal moment in 2023, expanding Kubernetes Project Infrastructure to multicloud. Turning to Kubermatic, renowned for its contributions to Kubernetes, a swift cross-cloud solution was implemented. Thanks to Kubermatic's engineers, the migration was efficient, keeping the project within budget and highlighting the impactful collaboration between CNCF and Kubermatic. Chris Aniszczyk, Chief Technology Officer at the Cloud Native Computing Foundation ![Chris Aniszczyk](/static/Chris-Aniszczyk.png) --- ## Embrace the Cloud Native Approach: Modernizing your virtualized workloads has never been easier. - **URL:** https://www.kubermatic.com/info/vmware-alternative/ - **Date:** 2026-03-30 - **Description:** Explore Your Kubernetes-Native Virtualization with Kubermatic. Say no to price hikes, support issues, and mandatory subscriptions. ![dark blue background with light blue rotating squares on top](/static/vm-hero-bg.svg) # Modernizing your virtualized workloads has never been easier. Seamless VMware Transition with the Right Infrastructure Strategy ## Explore Your Kubernetes-Native Virtualization with Kubermatic Searching for a soft migration from VMware cloud directory? Kubermatic can help by establishing a private cloud native infrastructure entirely using Kubernetes, eliminating the need to run multiple stacks. Our in-house experts will carefully evaluate your stack and identify a VMware alternative that promises **predictable pricing, high quality support** and **no mandatory subscriptions**. We will then initiate a pilot, and meticulously orchestrate your entire migration process ensuring that it is efficient and effective. ### It is time to move on from traditional virtualisation! [Talk to Our Experts](/info/vmware-alternative/#contact) ![](/static/moon-phases.jpg) ## Forget about vendor lock-ins. Embrace a cloud native approach to VMs and workloads right now! - #### Exhaustive Price Hikes ![Line with square point at end](/static/line-square-point.svg) ![](/static/dollar-sign-icon-blue-grad.svg) Say goodbye to the days of unforeseen and burdensome price increases. Kubermatic ensures a cost-effective solution, delivering results without breaking the bank. - #### Multiple stacks juggling ![Line with square point at end](/static/line-square-point.svg) ![](/static/person-speaks-icon-blue-grad.svg) Multiple stacks juggling era is gone. Get a unified solution, providing a common environment for both Kubernetes and virtualized workloads. With seamless networking and storage capabilities, say goodbye to the headache of managing disparate systems and hello to streamlined operations. - #### Mandatory Subscriptions and Shelfware ![Line with square point at end](/static/line-square-point.svg) ![](/static/bar-chart-icon-blue-grad.svg) Kubermatic breaks free from the norm by offering competitive pricing with a consumption-based subscription model. VMware solutions have reached their end-of-life. No more paying for features you don't need thanks to the viable alternative. With Kubermatic, you get what you pay for. ## Ensure a Smooth Migration from VMware with Minimal Disruption to Your Operations. ![](/static/vmw-slide-card-1.jpg) ### Cost-Effectiveness and Efficiency Kubermatic focuses on delivering results at a reasonable cost, ensuring that your investment aligns with your goals. ![](/static/vmw-slide-card-5.jpg) ### Unlimited Scale Achieve cost efficiency and flexibility by implementing streamlined Kubernetes-based management, leveraging autoscaling and auto healing capabilities for VMs. ![](/static/vmw-slide-card-2.jpg) ### Rapid Implementation of Feature Requests We understand the importance of staying competitive in a fast-paced technological environment. We will help you find the right solution where your feature requests are promptly addressed and implemented, empowering you to stay ahead of the curve. ![](/static/vmw-slide-card-3.jpg) ### Truly Independent and Infrastructure-Agnostic Break free from vendor lock-ins and leverage the possibility to establish a private cloud native infrastructure entirely using Kubernetes, eliminating the need to run multiple stacks. Kubermatic empowers you with the flexibility to choose what suits your needs best. We will help you analyze the existing stack and determine which parts are feasible for VM migration—whether to lift and shift, be completely rewritten, or undergo legacy modernization through cloud-native containerization. ![](/static/vmw-slide-card-4.jpg) ### Competitive Pricing We understand the value of your investment and ensure you get maximum value from your subscription, aligning with your budget and requirements. ## Gain Control of Your Infrastructure: Claim Your Free White Paper on VMware Migration Make the switch to the right solution for you today and experience a VMware Broadcom migration that is not just smooth but transformative. Simplify your operations, streamline your infrastructure and unleash the full potential of Kubernetes for your organization's cloud needs. Dive into the White Paper that sets you free to embrace a future of advanced Kubernetes solutions, cost-efficiently. - ![](/static/unlock-icon-black.svg) Updating your technology stack becomes essential. When infrastructure changes are on the horizon, it's the perfect time to rethink strategy and modernize your applications. Consulting with experts can help you navigate this process and find a cost-efficient solution that suits your needs. Unlock the insights and steps needed for a smooth transition into VMware alternative, empowering you with newfound flexibility and efficiency. - ![](/static/wheel-icon-black.svg) Our White Paper is designed to empower you with the knowledge on your road to VMware replacement required to navigate this transition effortlessly, ensuring that every step is a stride toward enhanced performance and resource optimization. Say goodbye to limitations and welcome a future where your operations align seamlessly with cutting-edge Kubernetes capabilities, all achieved in a cost-efficient manner. [Get Your Free White Paper](/static/White-Paper-The-Death-of-an-industry-standard.pdf) ## Having trouble finding the right Kubernetes solution for you? Explore various options and pathways for VMware migration with us. Let's find the ideal alternative tailored to your needs. If our form couldn't load correctly – This can have multiple reasons like ad blocker, not accepted cookies, JavaScript deactivated. However, you can still get in touch with us! Simply click on the button below, and you'll be able to submit the form and reach out to us for any inquiries or assistance you need. [Open form](https://share.hsforms.com/1OVoIH_G-TZmozLqdqw7HOA2piu8) © 2026 Kubermatic, GmbH. Kubermatic GmbH is not affiliated with VMware by Broadcom or Broadcom. VMware is a registered trademark of Broadcom in the United States and other territories. Other brand names are mentioned for information purposes only and may be the trademarks of their respective sources. --- ## Celebrating kcp joining the CNCF Sandbox! - **URL:** https://www.kubermatic.com/blog/celebrating-kcp-joining-the-cncf-sandbox/ - **Date:** 2026-04-30 - **Description:** Discover the exciting journey as kcp officially joins the CNCF Sandbox! Explore the milestones, innovations, and the vibrant community spirit that mark this celebration in the world of cloud-native technologies. - **Categories:** Best Practices - **Tags:** Kubernetes Exciting news! [kcp is now a CNCF Sandbox project](https://www.kcp.io/blog/2024/01/24/joining-the-cncf-sandbox/). This marks a significant milestone in the evolution of kcp. We have always kept the belief that kcp is the control plane of the future and enables building cloud native platforms that cannot be rivaled in scalability and user experience. Kubermatic is a proud sponsor of the application and are excited that kcp has joined the CNCF Sandbox and became a part of the CNCF landscape, unlocking organizations' ability to build and manage large-scale APIs. ## A Quick Insight Kcp extends the Kubernetes API, optimizing it for massive scalability, API management, and robust multi-tenancy. It introduces "Workspaces," acting as logical Kubernetes clusters that enforce boundaries between teams or organizations. Kcp's API exports enable a set of APIs for workspaces, a crucial building block for creating an as-a-service experience. ## A Swift Shift to Community Governance: Brief History In April 2023, Red Hat signaled a shift in focus away from kcp, inviting the community to take charge. A dedicated coalition established [a new project governance](https://github.com/kcp-dev/kcp/blob/main/GOVERNANCE.md) and [a fresh list of maintainers](https://github.com/kcp-dev/kcp/pull/2953), sparking momentum. The redesigned [kcp.io](https://www.kcp.io/) signifies the community-led revival. Recognizing kcp's place in the Kubernetes ecosystem, [Technical Oversight Committee (TOC)](https://www.cncf.io/people/technical-oversight-committee/) has successfully decided to accept it into the CNCF Sandbox program. Kubermatic, along with other organizations and individuals, embraced the idea of continuing kcp in a fully community-driven approach. ## Conclusion Kubermatic is more than excited about kcp.io joining the CNCF Sandbox and believes that this will help foster adoption of and contributions to kcp. As we eagerly anticipate what the future holds for kcp within the CNCF ecosystem, our collective efforts in community-driven innovation and collaboration stand as a testament to the strength and vitality of the open-source spirit. Stay tuned for more updates as we continue shaping the cloud-native landscape together! Read more about the official announcement here: https://www.kcp.io/blog/2024/01/24/joining-the-cncf-sandbox/ --- ## Impact of NIS2 Directive on Container Security in Europe - **URL:** https://www.kubermatic.com/blog/understanding-the-impact-of-nis2-directive-on-container-security-in-europe/ - **Date:** 2026-04-30 - **Description:** Explore the impact of the NIS2 Directive on container security within Europe's digital landscape. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Sebastian Scheele The digital landscape in Europe is poised for a significant shift with the emergence of the **NIS2 Directive**. The landscape of digital transformation intertwines with cybersecurity's evolution. Governments worldwide are taking strides to safeguard critical infrastructures from cyber threats. This directive, aiming to bolster cybersecurity and resilience, specifically affects **Kubernetes users**. In this blog post, **we'll delve into the core implications of NIS2 on container security and why it's crucial for Kubernetes enthusiasts across Europe to take notice**. ## Understanding NIS2 The NIS2 Directive stands as a landmark regulation addressing cybersecurity and digital infrastructure across the European Union. Its primary objective is to enhance the overall security posture of critical entities and digital service providers, with a specific focus on containerized environments and Kubernetes ecosystems. For European businesses NIS2 compliance could entail substantial investments in security tools and processes to meet elevated cybersecurity standards. This poses a challenge, particularly for mid-sized organizations with resource constraints. ### Impact on Container Security The NIS2 directive has profound implications for container security within Kubernetes environments. It places stringent requirements on incident reporting, risk management, and cybersecurity capabilities. Companies leveraging Kubernetes for their operations need to align with these directives, ensuring compliance and robust security measures within their containerized infrastructure. <div class="stacked-tiles"> <style> .stacked-tiles { display: flex; justify-content: space-between; } .stacked-tiles > img { width: 49%; height: auto; } </style> <img src="/static/persons-at-the-computer.jpg" alt="persons at the computer" width="392" height="262" loading="lazy"> <img src="/static/lock-laying-on-keyboard.jpg" alt="lock laying on keyboard" width="392" height="262" loading="lazy"> </div> ## Key Considerations ### Enhanced Incident Reporting NIS2 mandates timely incident reporting, emphasizing the need for prompt detection and response to security breaches within Kubernetes clusters. ### Strengthened Security Measures Organizations utilizing Kubernetes must elevate their security measures, ensuring encryption, authentication, access control, and continuous monitoring to align with NIS2 standards. ### Compliance Challenges Adhering to the NIS2 Directive presents compliance challenges, especially for enterprises operating intricate containerized environments. Ensuring alignment while maintaining operational agility becomes imperative. ## Conclusion As NIS2 transforms the cybersecurity landscape across Europe, Kubernetes users face a pivotal moment in bolstering their container security measures. Proactive steps to align with these directives will not only ensure compliance but also fortify the overall security posture of containerized environments. --- ## Navigating Cloud Native Horizon: Vision for 2024 - **URL:** https://www.kubermatic.com/blog/navigating-the-cloud-native-horizon-a-vision-for-2024-and-beyond/ - **Date:** 2026-04-30 - **Description:** Explore the future landscape of cloud-native technology in 2024 and beyond. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Sebastian Scheele In setting the stage for the year 2024, we project the trajectory of cloud native adoption, building upon and analyzing our predictions from January 2023. We aim to delineate the current position of cloud native technology along the adoption curve within expansive enterprises spanning diverse industries. In 2024, the landscape of container platforms and Kubernetes is set to witness significant shifts, reflecting both growing demand and looming challenges. Kubermatic, a leading provider of automated kubernetes management solutions, anticipates an upward trajectory in container platform demand worldwide. However, enterpise's competitiveness in this domain faces threats due to sluggish digitization, skills shortages, and inadequate educational focus on the subject. ## Impact of AI on Container Technology Within the realm of containers and Kubernetes, a pivotal query arises concerning the interplay between the rapid advancements in artificial intelligence (AI) and container technology. Enterprises are increasingly seeking container platforms to execute their AI models. Simultaneously, leveraging AI to streamline platform operations and tackle repetitive tasks becomes imperative. However, it's crucial to acknowledge that AI demands profound expertise, making it a domain for seasoned professionals rather than novices in the learning curve. <div class="stacked-tiles"> <style> .stacked-tiles { display: flex; justify-content: space-between; } .stacked-tiles > img { width: 49%; height: auto; } </style> <img src="/static/stacked-containers-1.jpg" alt="stacked containers image" width="392" height="350" loading="lazy"> <img src="/static/stacked-containers-2.jpg" alt="stacked containers image" width="392" height="350" loading="lazy"> </div> ## NIS2 Directive and Container Security The impending NIS2 Directive for the European Union, effective from October 2024, will influence container security, thrusting container platforms into the spotlight. Legacy IT systems struggle to align with the "cloud native" evolution. While cloud native technology inherently offers resilience, it also presents fresh challenges for enterprises. ## Economic Outlook and IT Projects Amid economically uncertain prospects, there arises the question of whether this will impact the initiation of new container projects. Stagnation in digitalization and the reluctance to adopt new technologies could widen the gap between local and international competitors. Addressing this divergence should be a focal point for Enterprises, especially considering a growth opportunity there competitors. ## Skill Shortages and Educational Focus Enterprises grapple with a persistent shortage of container experts, attributed partly to the neglect of container-related education in universities and educational institutions. This reliance on importing knowledge results in project delays, affecting competitive positioning. ## Future Outlook for Containers and Kubernetes Containers and Kubernetes will retain a prominent position on the agendas of many companies in 2024. However, the emphasis will increasingly shift toward aspects of security and stabilization. ## Conclusion The landscape of container technology in 2024 presents both promise and challenges. To maintain competitiveness, Enterprises must address skill shortages, prioritize education, and embrace technological advancements. **It's pivotal to assess your digital transformation objectives and gauge your IT organization's progress along the cloud native journey.** Consider these pivotal questions: - Have you established a robust cloud native strategy, roadmap, and architecture? - Are you fostering a culture of transformation within your IT team, nurturing a shift in skills, mindsets, and processes? - Does your team possess the necessary technical prowess for Kubernetes and other cloud native tools? - Encountering challenges along this path? Reach out to us. We specialize in resolving these hurdles and accelerating your stride toward the cloud native landscape. **Explore our Kubermatic Kubernetes Platform Enterprise Software Solution and request a [Demo today](/demo/).** Kubermatic Kubernetes Platform is an enterprise software platform company that enables enterprises and service providers to deliver automated multi-cloud operations. Kubermatic Kubernetes Platform automates thousands of Kubernetes clusters across any infrastructure on multi-cloud, on-prem and edge with unparalleled density and resilience. With Kubermatic Kubernetes Platform, developers work with the cloud native stack they prefer and have freedom of choice and a consistent experience across all environments. By automating operations, teams focus on writing the next generation of ground-breaking applications, not operations. --- ## Meet KKP 2.24: Stability Enhanced With Exciting Features - **URL:** https://www.kubermatic.com/blog/kkp-2-24-stability-enhanced-with-exciting-features/ - **Date:** 2026-04-30 - **Description:** Explore the exciting features and latest enhancements of the KKP 2.24 release that make your Kubernetes journey smoother. - **Categories:** Products - **Tags:** KKP - **Authors:** Csenger Szabo We're excited to announce the Kubernetes Platform 2.24 release that delivers the latest versions of open source software to make your Kubernetes journey even smoother. ## Cilium to be default networking tool of User Clusters CNCF has announced the graduation of Cilium, which is an eBPF-powered open source solution for network connectivity, security, and observability in cloud-native environments. Cilium, which initially served as a Container Networking Interface, has expanded its capabilities to include network policy enforcement, meshing multiple Kubernetes clusters, encryption, ingress and egress gateway, and more. Cilium's graduation signifies its evolution into a comprehensive networking and security solution in the Kubernetes ecosystem. With that, from 2.24, Cilium is going to be the default networking solution for User Clusters in KKP. ## Default App Catalog for Seamless Integration In KKP 2.24, we're improving our application installation process by introducing a default App Catalog. With this addition, you can effortlessly deploy your applications into KKP User Clusters that are necessary for development purposes, like Argo CD, Flux, Nginx, Cert-Manager, MetalLB, Kube-VIP, Istio, Falco and Trivy. ## Keeping Up with Kubernetes 1.28 We understand the importance of staying up-to-date with the latest Kubernetes versions. In this release, we're excited to bring support for Kubernetes 1.28 into KKP. ## Flexible IPAMPool Range Allocation KKP 2.24 introduces the flexibility to modify allocation ranges within IPAMPools. Now, you can increase the number of allocated IPs without the hassle of re-adding data centers. This enhancement simplifies IP management, making it easier to adapt to the changing requirements. ## Enhanced vSphere Integration For vSphere users, we're rolling out a feature that allows for the propagation of cluster tags to folders managed by KKP. If you specify tags at the user cluster level, these tags will now be seamlessly propagated to the folders managed by KKP as well. Note that this change won't affect pre-existing folders created outside of KKP, but it simplifies tag management within KKP. ## Streamlining Offline Image Management KKP 2.24 extends the kubermatic-installer mirror-images command with an option to export all images as a tarball. This new feature is perfect for creating air-gapped OCI repositories, ensuring smooth installations even in offline environments. Just copy the archive to a USB drive, and you're ready to initialize your repository! ## Customizing the Dex Theme Customer branding is essential, and we're here to support it. With KKP 2.24, you can now update the theme of Dex using a values.yaml file. No more need to maintain individual files in a theme directory. This change simplifies branding updates, allowing you to focus on what matters most: your unique brand identity. ## Fine-Tuning Your Admin Settings Administrators can now hide or show operating systems when creating machine deployments in the admin settings. This added flexibility ensures that your settings align with your specific needs. ## Multiple Networks for vSphere KKP 2.24 introduces support for configuring multiple networks for vSphere. We've simplified the process by moving away from *vmNetName* for clusters and presets. Instead, we now use *networks*, making network configuration more straightforward and flexible. ## VMware Cloud Director Enhancements For VMware Cloud Director users, this release brings support for configuring placement and sizing policies for machines. With these policies categorized as compute policies, you can fine-tune your infrastructure to meet your specific requirements. ## EBS Volume Encryption for AWS Finally, KKP 2.24 adds support for configuring EBS Volume Encryption for the AWS provider. This enhancement strengthens security and data protection for your AWS deployments. ## KubeVirt: Support for OCI VM Image Source KubeVirt VM images no longer need to be served over `https://*` but can also be served over `docker://*`, and the images can be found at https://quay.io/organization/kubermatic-virt-disks ## Have a good time trying out the new features! We're committed to making KKP the best Kubernetes platform for your needs, and this release is a significant step forward. We hope you find these new features and improvements valuable for your projects. Thank you for being a part of the Kubermatic community, and we look forward to your feedback on KKP 2.24. If you find our contributions valuable, we kindly encourage you to leave a star on our GitHub repository. As always, please don't hesitate to reach out with any questions or suggestions via [Contact Us](/contact-us/) form. --- ## Kubermatic & Fraunhofer HHI: Containerized 5G Network - **URL:** https://www.kubermatic.com/resources/kubermatic-and-fraunhofer-hhi-demonstrate-fully-containerized-5g-campus-network/ - **Date:** 2024-03-21 - **Description:** Kubermatic and our partner Fraunhofer HHI were able to successfully run a private 5G Campus Network on Kubernetes end-to-end. # Kubermatic & Fraunhofer HHI demonstrate fully containerized 5G Campus Network ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Business Case At [CampusOS Plugfest](https://campus-os.io/campusos-plugfest-23-27-october-2023-sience-tech-space-at-fraunhofer-hhi/), Kubermatic and our partner [Fraunhofer HHI](https://www.hhi.fraunhofer.de/en/departments/wn.html) were able to successfully run a private 5G Campus Network on Kubernetes end-to-end. The Kubernetes cluster consisted of two edge machines, hosting the fully virtualized open source 5G base station and 5G core, and one virtual machine provisioned in a Fraunhofer HHI data center. It was fully set-up using [KubeOne](https://www.kubermatic.com/products/kubermatic-kubeone/). As a radio unit, a software-defined radio device was chosen. On the software side, the team installed a [free5G Core](https://free5gc.org/) and [OpenAirInterface RAN](https://openairinterface.org/oai-5g-ran-project/) into the cluster. As the cni plugin, [Multus](https://github.com/k8snetworkplumbingwg/multus-cni) was chosen to achieve performant network segregation. During our tests, we ran the 5G setup in two different models. Firstly we ran the 5G Core close to the RAN setup. Afterwards we moved the 5G core onto the remote VM in order to simulate a migration to a data center. Leveraging Kubernetes we were able to quickly re-deploy the core, requiring only NodeSelector changes in the config. We are happy to announce that the setup is fully based on open-source solutions and are excited for further developments in the 5G space. Want to dive into the future of containerized 5G? Contact us via the following form: [https://www.kubermatic.com/contact-us/](https://www.kubermatic.com/contact-us/) ![side-by-side arrangement of edge hardware](/static/network-devices-connected-each-others-bc.jpg) *side-by-side arrangement of edge hardware* ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Securing Manufacturing Assembly Lines with Kubernetes - **URL:** https://www.kubermatic.com/customers/chemical-industry/ - **Date:** 2026-06-23 - **Description:** Exploring the benefits of Industry 4.0, the challenges it presents, and how Kubermatic Kubernetes Platform (KKP) empowers manufacturing operations with unparalleled data management, availability, scalability, and security. # Securing Manufacturing Assembly Lines with Kubernetes ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Outcomes - ![Console icon](/static/console-teal-icon.svg) ### 100+ software engineers developing next-gen software applications on a single harmonized IT platform - ![Light bulb icon](/static/bulb-gold-icon.svg) ### 100% availability across clusters globally - ![Ship wheel icon](/static/wheel-pink-icon.svg) ### Extend infrastructure in minutes, not days ## Situation: Industry 4.0 Industry 4.0 has transformed traditional manufacturing and industrial processes, enabling enterprises to become more efficient, optimize resources and stay competitive in the market. By leveraging AI-powered cyber physical systems, companies with manufacturing assembly lines can nowadays access real-time information which enhances a more accurate data analysis, smart automation and production agility, all while achieving significant cost reductions. **Reaping the rewards of Industry 4.0** - **Improved productivity:** Industry 4.0 enables data-driven decision making and optimizes monitorization as well as resource utilization. - **Enhanced customer experience:** Every time more enterprises are able to manufacture customized products and adapt rapidly to changes, which become an added value to customers. - **Predictive maintenance:** As companies become more flexible, it's easier to minimize unplanned downtimes and prevent costly interruptions. - **Easier compliance:** The possibility of real-time data monitoring and automated reporting makes compliance more streamlined and manageable. ![Robot icon](/static/robot-white-img.svg) ![Factory building](/static/factory-gradient-img.svg) ## Challenges of Embracing Industry 4.0 To grasp the many benefits of Industry 4.0, businesses need to understand that it also comes with challenges, especially when dealing with multiple manufacturing lines, and know how to mitigate them. - ### Interconnecting multiple manufacturing lines Obtaining information transparency, optimal performance and cost reduction with multiple interconnected manufacturing lines can be a complex issue. - ### Balancing centralization & self-sufficiency Each manufacturing line should be self-sufficient taking decentralized decisions, however when excessive, self-sufficiency can lead to duplication of effort. A good balance leads to a reduction of revenue loss. - ### Rise of cyber attacks High connectivity in the industry has increased the number of cyber attacks, which compromise digital security. - ### Increase in data collection & consumption Every time a more resilient system is needed to cope with the high data mass. ## Why should you secure your manufacturing line with KKP - ![Rocket icon](/static/rocket-grad-icon.svg) ### Master data management to enable faster decision-making KKP handles colossal data volumes generated by industrial machines and processes the information in an environment of your choice with the most efficient use of compute resources possible. - ![Centralized icon](/static/centralized-grad-icon.svg) ### Experience limitless availability KKP delivers consistent performance across all infrastructures embracing interconnectivity. - ![Clock icon](/static/clock-grad-icon.svg) ### Empower interoperability to enhance faster scaling Prevalence of diverse devices is common in manufacturing environments. KKP not only acknowledges this diversity but actively embraces it through its expansive ecosystem and robust plugin support. - ![UI panel icon](/static/ui-panel-grad-icon.svg) ### Leverage unmatched deployment flexibility Say hi to flexible, agile and efficient operations as KKP utilizes a declarative approach for managing both software and hardware. - ![Cycle icon](/static/cycle-grad-icon.svg) ### Benefit from a seamless experience Discover an incredible ease of use with KKP, as it minimizes cognitive load for developers and operators. Get ready to modify and adjust your systems without encountering any obstacles. - ![Lock icon](/static/lock-grad-icon.svg) ### Integrate security and observability KKP combines security and observability into a single, adaptable, open-source solution to create a secure and transparent operating environment. - ![Structural chart icon](/static/struct-grad-icon.svg) ### Obtain unmatched density and resilience Thanks to the multiple seed clusters in KKP, management is independent from workloads. Benefit and get as a result unparalleled density and resilience. - > If it works with kubernetes, it works with KKP! --- ## Kubermatic named in Gartner® Cool Vendors™ - **URL:** https://www.kubermatic.com/blog/kubermatic-named-in-gartner-cool-vendors/ - **Date:** 2026-04-30 - **Description:** Kubermatic named a 'Cool Vendor' in the Gartner® Cool Vendors™ in Container Management - **Categories:** Company - **Tags:** Announcements Kubermatic GmbH, a leading provider of automated kubernetes management solutions, has been recognized as one of the five 'Cool Vendors' in the August 2023 report by Gartner titled 'Cool Vendors in Container Management'. Kubermatic is the only European vendor to be recognized in the August 2023 report by Gartner titled 'Cool Vendors in Container Management'. "We are thrilled to be recognized by Gartner as one of the 'Cool Vendors'", said Sebastian Scheele, CEO of Kubermatic. "We believe this recognition is a testament to our team's hard work and dedication to providing the best possible Kubernetes management solutions to our customers. We are committed to empowering businesses to harness the power of cloud native with Kubernetes, and we believe that automation is key to achieving this goal. This recognition gives us further motivation to continue developing and delivering innovative automation solutions that help our customers simplify and accelerate their cloud native and kubernetes journey." As the top European committer to the Kubernetes project, Kubermatic is a trusted provider of enterprise-grade software solutions, professional services, and support to help organizations safely navigate and accelerate their cloud native transformation. With the Kubermatic Kubernetes Platform (KKP), organizations can easily operate thousands of Kubernetes clusters on any infrastructure, empowering them to achieve their goals with greater speed and efficiency. Renowned enterprises such as Lufthansa, Bosch, Siemens, Cube Bikes, Allianz and T-Systems rely on Kubermatic to lead their cloud native journey. Headquartered in Hamburg, Germany, Kubermatic is well-positioned to support organizations worldwide in achieving their digital transformation goals. <br/> --- <small> <em> <strong>Disclaimer:</strong> The GARTNER COOL VENDOR badge is a trademark and service mark of Gartner, Inc., and/or its affiliates, and is used herein with permission. All rights reserved. Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s Research & Advisory organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose. </em> </small> <br/><br/><br/><br/> --- ## Born in the Cloud growing at the Edge? - **URL:** https://www.kubermatic.com/resources/born-in-the-cloud-growing-at-the-edge/ - **Date:** 2023-10-23 - **Description:** This keynote addresses the key challenges of edge computing and how Kubernetes enables efficient edge deployments and makes cost-effective edge computing a reality through a cloud-native approach. # Born in the Cloud growing at the Edge? ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Sebastian Scheele's Talk at ContainerDays 2023 Kubernetes, originally developed for the cloud, is seamlessly transitioning into the evolving landscape of edge computing. As the concept of “edge” takes on different meanings, edge computing remains niche compared to the cloud. However, the integration of new use cases, such as artificial intelligence (AI), is driving the adoption of edge computing. AI’s demand for fast local decision making that reduces latency and data transfers is critical, especially in areas such as Industry 4.0 and autonomous driving This keynote addresses the key challenges of edge computing and how Kubernetes enables efficient edge deployments and makes cost-effective edge computing a reality through a cloud-native approach. **Speaker: Sebastian Scheele, CEO & Co-Founder at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Container Days 2023: Ephemeral Containers: Running Go Debugger in Kubernetes - **URL:** https://www.kubermatic.com/resources/cds-2023-ephemeral-containers-in-action-running-a-go-debugger-in-kubernetes/ - **Date:** 2024-10-16 - **Description:** This talk discusses the practicality of launching a Go debugger (Delve) within an ephemeral container to remotely debug an application both on the CLI and in VS Code. # Ephemeral Containers in Action: Running a Go Debugger in Kubernetes - CDS 2023 ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Marvin Becker's Talk at ContainerDays 2023 The modern observability stack has transformed the way you troubleshoot issues in a microservice environment. Some situations however, ask for investigation of a single application pod that seems to be misbehaving. Ephemeral containers provide a way to attach to a seemingly problematic pod without restarting it.This allows developers to observe an issue in a live or staging environment running on top of Kubernetes. We will discuss the practicality of launching a Go debugger (Delve) within an ephemeral container to remotely debug an application both on the CLI and in VS Code, highlighting the requirements and possible limitations one might encounter when trying to set up a similar troubleshooting routine. As part of that, we will explore the API for ephemeral containers and the current implementation in kubectl. While the talk will use Go and Delve as an example, the considerations and steps presented are of universal importance to running a debugger for your language stack of choice. **Speaker: Marvin Beckers, Team Lead at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Securing the Kubelet API: Why is it important? - **URL:** https://www.kubermatic.com/resources/securing-the-kubelet-api-why-is-it-important/ - **Date:** 2023-10-23 - **Description:** This talk explores the importance of securing the Kubelet API and the risks of exposing it with a demo. # Securing the Kubelet API: Why is it important? ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Koray Oksay's Lightning Talk at ContainerDays 2023 Kubelet is a crucial component of Kubernetes that runs on each node and is responsible for managing container runtime, monitoring container health, and reporting node status to the control plane. However, this critical component is often overlooked regarding security, leaving the cluster vulnerable to potential attacks. This talk will explore the importance of securing the Kubelet API and the risks of exposing it with a demo. **Speaker: Koray Oksay, Kubernetes Consultant at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Datacenter in a Suitcase a real small edge case - **URL:** https://www.kubermatic.com/resources/datacenter-in-a-suitcase-a-real-small-edge-case/ - **Date:** 2023-10-23 - **Description:** In this session, we want to explore how to build a true portable datacenter what can travel easily and brings enough power to support certain applications. # Datacenter in a Suitcase a real small edge case ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Mario Fahlandt's Talk at ContainerDays 2023 The challenges brought to the cloud native community are ever expanding. Luckily also the tools and the hardware support is expending. Edge is a topic which appears ever more often. The challenges there are as much as the use cases. Here we want to explore how to build a true portable datacenter what can travel easily and brings enough power to support certain applications. A datacenter which fits in a suitcase and is possible to bring to remote locations to help there to bring computing power directly to the place to be. With the help of various CNCF projects, this comes to live. The base is a MiniITX Clusterboard with multiple ARM based hardware nodes. On top the utilization will take place with KubeVirt, and we utilize the small control plane approach of the Kubermatic Kubernetes platform to create a real multi cluster Datacenter. Follow me in this Case Study to unlock a really portable Datacenter. This case study and the open source approach of its design is aimed to give a possible solution for small real edge datacenters. An easy to built public available blueprint for a portable datacenter shows the strong parts of our Open Source community. The utilization of multiple CNCF open source projects and the sharing of the created blueprint to everyone. So it will be easy for more people to explore the edge world by themselves and can create their on solutions based on it **Speaker: Mario Fahlandt, Kubernetes Consultant at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Look Ma, No secrets in my Kubernetes Cluster! - **URL:** https://www.kubermatic.com/resources/look-ma-no-secrets-in-my-kubernetes-cluster/ - **Date:** 2023-10-23 - **Description:** In this session, dive into Kubernetes secrets and secret management! # Look Ma, No secrets in my Kubernetes Cluster! ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Vijay Dharap's Talk at ContainerDays 2023 Kubernetes Secrets are major maintenance and security headache. Traditionally, 3-4 approaches exists for secret mgmt. 1. Define secrets in Git as plain-text and deploy them. Restrict access to git repo. 2. Use git level encryption like git-crypt or Mozilla SOPS and encrypt the files which contain secrets 3. Create encrypted secret values using Sealed Secrets. Store them in git. Use sealed-secrets operator in cluster which reads encrypted CRD values and decrypt them and create k8s secrets for you. 4. Use External Secrets operator to manage secrets in cloud secret management tools All 4 approaches have trade-offs like Access control issues, git history cleanup, no-encryption at runtime, Secret-Store-CSI takes different approach. It allows you to make use of standard cloud based secret-mgmt solutions like AWS secrets manager or established players like vault to manage secrets and access to them. Secret-Store-CSI is a Container Storage Interface and so it directly mounts secrets as a storage volume in the POD! There is no actual Kubernetes secret resource created at all. It also syncs any change in secret in external secret manager in the pod. In the demo - 1. Secret-store-CSI is deployed on a k8s cluster in AWS. 2. AWS kube2iam restricts access to aws secrets manager to only the operator pod. 3. Demo app uses secret value provided by the operator. 4. We change secret in secret mgr and we see app get reloaded (due to stakator-reloader) and uses new value **Speaker: Vijay Dharap, Tech Lead at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Airgapped Kubernetes - **URL:** https://www.kubermatic.com/resources/airgapped-kubernetes/ - **Date:** 2023-10-23 - **Description:** Watch this talk and learn how Kubernetes would work in an air-gapped scenario. # Airgapped Kubernetes ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Hannes Probst's Talk at ContainerDays 2023 What if you want to install Kubernetes, but your nodes are not connected to the internet? If you are concerned about data protection and critical infrastructure, while at the same time wanting to leverage the benefits of Kubernetes, the solution demonstrated in this talk might be helpful. Typical enterprise architecture applies many layers of protection to isolate workloads, most notably through firewalls. Traffic needs to be explicitly allowed to leave the protected networks. Everything else is blocked. This is an attempt to get as many “gaps” between the outside and the inside as possible. The next logical step in this setup is to reach a so-called air-gaped environment. How would Kubernetes work in such an isolated and air-gapped scenario? Usually, while installing Kubernetes, many artifacts and binaries need to be downloaded from all over the place. Also, future clusters usually rely on a lot of outside resources. We talk about a possible architecture for such use cases. Let us get started with an easy-to-understand overview. Then we will dive deeper and cover details about a reference implementation we put together on AWS, with a fully functional air-gapped Multicluster Kubernetes environment. **Speaker: Hannes Probst, Technical Infrastructure Consulant at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Terms and Conditions - **URL:** https://www.kubermatic.com/terms-and-conditions/ - **Date:** 2025-02-13 - **Description:** Terms and Conditions of Kubermatic GmbH. # Terms and Conditions ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Terms of Use Your use of and access to Kubermatic Products and Services are governed by the Terms and Conditions of the agreement under which you obtain those services. ## Standard Contractual Clauses Our terms of use reference the following supporting documents, as applicable to your subscription: **NDA** [Mutual NDA](/terms-and-conditions/nda/) **Customer Contracts** [Resource-based Pricing](/static/terms/Kubermatic_Resource-based_Pricing_V202401.pdf) **Germany** [General Terms and Conditions for Services](/static/terms/Kubermatic_General_Terms_and_Conditions_for_Services_V202308.pdf) [License and Subscription Terms](/static/terms/Kubermatic_License_and_Subscription_Terms_Germany_V202308.pdf) **International** [General Terms and Conditions for Services](/static/terms/Kubermatic_General_Terms_and_Conditions_for_Services_V202308.pdf) [License and Subscription Terms](/static/terms/Kubermatic_License_and_Subscription_Terms_International_V202308.pdf) **Partner Contracts** **Germany** [Reseller Partner Terms](/static/terms/Kubermatic_Partner_Agreement_Reseller_Partner_Schedule_Germany.V17.08.22.pdf) [Referral Partner Terms](/static/terms/Kubermatic_Partner_Agreement_Referral_Partner_Schedule_Germany.V17.08.22.pdf) [Affiliate Partner Terms (Commercial agent)](/static/terms/Agency_Agreement_Handelsvertreter_V.122022.pdf) [Affiliate Partner Terms (Occasional agent)](/static/terms/Referral_Fee_Agreement_Gelegenheitsvermittlung_V.122022.pdf) **International** [US-Reseller Terms](/static/terms/Kubermatic_Partner_Agreement_Reseller_Partner_Schedule_US-Law.V11.08.22.pdf) **EULA** [End User License Terms](/static/terms/Kubermatic_Reselling_Partner_End_User_License_Agreement.pdf) ## Supporting Documents [Commercial Support Service Levels Guidelines](/static/terms/Kubermatic_Commercial_Support_Service_Levels_Guidelines_V202308.pdf) ## Data Protection and Privacy [Data Processing Agreement](/static/terms/Kubermatic_DPA_V202401.pdf) ## ISO Certificates [ISO 27001 Information Security Certification](/static/ISO-27001_British-Assessment-Bureau-Certificate.pdf?y=2024) [ISO 9001 Quality Management Certificate](/static/ISO-9001_British-Assessment-Bureau-Certificate.pdf?y=2024) --- ## Kubernetes: Location Change for Linux Packages - **URL:** https://www.kubermatic.com/blog/kubernetes-changing-the-location-of-linux-packages/ - **Date:** 2026-04-30 - **Description:** The legacy Kubernetes Google-hosted package repositories have been deprecated and will be frozen from September 13. What do you need to know about this change and what steps do you need to take? - **Categories:** Products, Best Practices - **Tags:** KubeOne, KKP, Kubernetes - **Authors:** Marko Mudrinić ## Announcing the New Package Repositories On August 15, 2023, **the [Kubernetes project announced](https://kubernetes.io/blog/2023/08/15/pkgs-k8s-io-introduction/) the new community-owned Linux package repositories available at `pkgs.k8s.io`.** These new repositories are a replacement for the legacy, Google-hosted, package repositories (`apt.kubernetes.io` and `yum.kubernetes.io`) that the Kubernetes project has used since Kubernetes v1.5, or for the past seven years! The new repositories are bringing **many benefits**, including: - better control over the structure of repositories - fine-grained control for dependencies like `cri-tools` and `kubernetes-cni` - ability to publish packages for Kubernetes prereleases and other Kubernetes subprojects - enable the Kubernetes Release Managers to publish packages on their own In addition to that, the Kubernetes community has been working very hard to migrate to the infrastructure owned by the community. Previously, most of the infrastructure was owned by Google (including the legacy packages repositories) and the community didn't have management access to that infrastructure. To enable the Kubernetes project to grow further, it's critical to migrate to the community-owned infrastructure and resources. **Migrating to the new community-owned package repositories marks a big milestone for the project's goal**. ## Deprecating and Freezing the Legacy Repositories Migrating completely to the community-owned repositories is required for the Kubernetes project to enjoy all the benefits. The project made the following decisions: - The legacy package repositories are **deprecated** as of **August 31, 2023** - The Kubernetes project will **stop** publishing new packages to the legacy repositories as of **September 13, 2023**, following the Kubernetes patch releases scheduled for September. In other words, this means that: - The Kubernetes patch releases scheduled for September 2023 (v1.28.2, v1.27.6, v1.26.9, v1.25.14) will be published **both** to the new repositories **and** to the legacy repositories - v1.25, v1.26, v1.27, and v1.28 patch releases scheduled for October 2023 and onwards will have packages published **only** to the new repositories - All Kubernetes minor releases starting with v1.29 will have packages published only to the new repositories ## Is Kubermatic Kubernetes Platform (KKP) Affected by This Change? **Kubermatic Kubernetes Platform (KKP) does not use package repositories**, therefore it is not affected by this change. However, please continue reading as you might be affected in other ways. ## Is Kubermatic KubeOne Affected by This Change? **Yes, Kubermatic KubeOne is affected.** Kubermatic KubeOne uses the package repositories to install `kubeadm`, `kubelet`, and `kubectl` on the control plane and static worker nodes. **You're only affected if your Kubernetes cluster is created with KubeOne versions prior to v1.7.0 and v1.6.3.** ### I'm Affected. How Do I Migrate to the New Repositories? **The migration to the new package repositories is fully automated**. All you need to do for now is to upgrade your KubeOne version to v1.6.3 or v1.7.0. The next time you upgrade your cluster or add a new static worker node, all your **control plane** and **static worker** nodes will be migrated to the new community-owned package repositories (`pkgs.k8s.io`). ### Is There Anything That I Should Pay Attention To? If you restrict traffic based on IP addresses or domain names, this change might affect you. The Kubernetes project doesn't provide a list of IP addresses or domain names because `pkgs.k8s.io` is supposed to work as a redirector to a set of multiple backends that can change at any time. Restrictive control mechanisms like man-in-the-middle proxies or network policies that restrict access to a specific list of IP addresses and domain names will break with this change. For these scenarios, it's encouraged to mirror the release packages to a local package repository that you have strict control over. ## Are Kubermatic machine-controller and Operating System Manager (OSM) Affected by This Change? No, the Kubermatic machine-controller and Operating System Manager (OSM) **are not affected** by this change. This means that **worker nodes managed by machine-controller and OSM** in your KubeOne cluster are **not** affected. ## Am I, as a Kubernetes Operator, Affected by This Change in Any Other Way? If you're installing `kubectl` on your Linux PC from the package repositories, you likely need to migrate to `pkgs.k8s.io` on your PC. For more information about this, please check [the official deprecation announcement](https://kubernetes.io/blog/2023/08/31/legacy-package-repository-deprecation/). ## What Else Should I Know About These New Repositories? **As a KubeOne user, you shouldn't notice any difference at all**. If you wish to familiarize yourself with how the new repositories work, we recommend checking out [the official pkgs.k8s.io announcement](https://kubernetes.io/blog/2023/08/15/pkgs-k8s-io-introduction/). ## Conclusion This is a significant change for many Kubernetes users, but it's sometimes important to make such changes to ensure the well-being of the project. It is not only the many benefits that the new repositories offer, but also the fact that the **shift to community-owned infrastructure reflects a crucial milestone in the project's growth**. The legacy package repositories have been deprecated as of August 31, 2023, with new packages ceasing publication on September 13, 2023. What you need to know: **KKP remains unaffected by this change, Kubermatic KubeOne users will need to migrate by upgrading to v1.6.3 or v1.7.0 for seamless integration with the new community-owned repositories**. Ultimately, we are happy to see such a positive evolution for the Kubernetes ecosystem. --- ## Crossplane in the wild - **URL:** https://www.kubermatic.com/resources/crossplane-in-the-wild/ - **Date:** 2023-08-10 - **Description:** Explore the opportunities that Crossplane offers in building an integrated Infrastructure as Code solution, centered around Kubernetes. # Crossplane in the wild ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## A real step forward in cloud native infrastructure provisioning? A partner webinar with Scandio GmbH. Explore the opportunities that Crossplane offers in building an integrated Infrastructure as Code solution, centered around Kubernetes. These possibilities as well as the concepts of Crossplane are illustrated in this webinar by two examples inspired by real-world customer projects. First, let’s take a look at how an existing infrastructure stack for running a development toolchain on Azure Kubernetes Service initially set up on Terraform was migrated to a hybrid ArgoCD / Terraform deployment and finally to a Kubernetes native ArgoCD / Crossplane workflow. We will go over the general process of migrating existing infrastructure, the improvements achieved, and future plans in regards to multi-tenant and multi-cluster infrastructure. Second, we will show a possible architecture of a centralized, multi-tenant Everything-as-a-Service platform built with Crossplane and KKP. We will briefly outline the platform architecture that enables multi-tenancy and show how Crossplane is also used to control the platform itself. Based on the example of the “Platform Account”, we will show you the true power of Crossplane to define your own opinionated APIs. **Speakers: Daniel Kraus, Kubernetes Consultant at Kubermatic and Benjamin Ritter, Cloud Engineer at Scandio.** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Kubermatic Kubernetes Platform: Capterra Shortlist - **URL:** https://www.kubermatic.com/blog/kkp-earns-a-spot-in-the-capterra-shortlist-for-devops-software/ - **Date:** 2026-04-30 - **Description:** Kubermatic is proud to announce that Kubermatic Kubernetes Platform (KKP) is recognized and mentioned in the Capterra Shortlist for DevOps Software. - **Categories:** Products - **Tags:** KKP Kubermatic Kubernetes Platform is proud to announce its mention in the flagship report of [Capterra](http://capterra.com), a free online service that helps organizations find the right software. KKP is recognized in the [2023 Shortlist for DevOps Software](https://www.capterra.com/devops-software/shortlist/). *Capterra Shortlist is an independent assessment that evaluates user reviews and online search activity to generate a list of market leaders in the software space that offer the most popular solutions. (Have a look at the Capterra Shortlist methodology [here](https://www.capterra.com/resources/research-methodologies/).)* Here's what Kubermatic CEO, Sebastian Scheele, has to say about this incredible achievement: "It fills us with immense pride to see our platform being recognized and mentioned in the prestigious flagship report of Capterra. This achievement reaffirms our commitment to excellence and innovation, and we remain dedicated to empowering businesses worldwide with cutting-edge open-source & kubernetes technology and unlocking the true potential of their containerized applications." Our users have made this possible! With an overall rating of [4.6 out of 5](https://www.capterra.com/p/199419/Kubermatic-Kubernetes-Platform/reviews/), we received some stellar reviews on Capterra: > ***"An easy way to manage your instance deployments, it is easy to create a flow that handles our code merge You can see all the time what's happening with your CI/CD cycles with real-time monitoring It also has a clean Dashboard to manage your applications"*** > > *[[Yehanny O.](https://www.capterra.com/p/199419/Kubermatic-Kubernetes-Platform/reviews/4601503/)]* > ***"We are using this tool for the last 2 years on production and we really never faced any issues related to CI/CD. Also once it is deployed it really automates a lot of processes."*** > > *[[Ranu S.](https://www.capterra.com/p/199419/Kubermatic-Kubernetes-Platform/reviews/4006702/)]* > ***"It supports multiple Kubernetes nodes. You can manage and monitor many Kubernetes clusters."*** > > *[[Osman D.](https://www.capterra.com/p/199419/Kubermatic-Kubernetes-Platform/reviews/3702071/)]* Want to share what you like about our product? Add your review [here](https://reviews.capterra.com/new/199419). **About Kubermatic:** Kubermatic empowers organizations worldwide to fully automate their Kubernetes and cloud native operations across multi-cloud, edge and on-prem As the top European committer to the Kubernetes project, Kubermatic is a trusted provider of enterprise-grade software solutions, professional services, and support to help organizations safely navigate and accelerate their cloud native transformation. With the Kubermatic Kubernetes Platform (KKP), organizations can easily operate thousands of Kubernetes clusters on any infrastructure, empowering them to achieve their goals with greater speed and efficiency. Renowned enterprises such as Lufthansa, Bosch, Siemens, and T-Systems rely on Kubermatic to lead their cloud native journey. Headquartered in Hamburg, Germany, Kubermatic is well-positioned to support organizations worldwide in achieving their digital transformation goals. Find us at: [www.kubermatic.com](/) Follow us on: [Twitter](https://twitter.com/Kubermatic), [LinkedIn](https://www.linkedin.com/company/kubermatic), [Github](https://github.com/kubermatic/) **About Capterra:** *Capterra is a software reviews and selection platform that connects businesses to the right technology. Compare software, read and leave reviews, and access objective insights that empower business growth.* <br/> --- <small> <em> <strong>Disclaimer:</strong> The Capterra Shortlist badge is a service mark of Gartner, Inc., and/or its affiliates, and is used herein with permission. All rights reserved. The Capterra Shortlist report constitutes the subjective opinions of individual end-user reviews, ratings, and data applied against a documented methodology; they neither represent the views of, nor constitute an endorsement by, Capterra or its affiliates. </em> </small> <br/><br/><br/><br/> --- ## Multi-Cluster Deployment Management with Nephio: A first Guide - **URL:** https://www.kubermatic.com/blog/multi-cluster-deployment-management-with-nephio-a-first-guide/ - **Date:** 2026-04-30 - **Description:** Learn how Nephio simplifies complex deployment management across multiple clusters. Follow our guide to set up three Git repositories and Kubernetes clusters for streamlined multi-cluster deployments. - **Categories:** Products, Best Practices - **Tags:** KKP, Kubernetes - **Authors:** Simon Bein ## Introduction In this blogpost we want to demonstrate how you can use nephio to manage deployments that span across multiple clusters. We are going to create three git repositories and three k8s clusters in total. Their purposes are as follows: - nephio-master git repository: In this repository we are storing the deployment of the nephio master server - nephio edge-1 & edge-2 git repository: In this repository we store the desired configurations of our applications which should be deployed on the edge cluster - nephio-master cluster: In this cluster the core nephio components reside. The cluster acts as a management cluster for the edge clusters - edge-cluster 1 & 2: In these clusters we want to deploy our workload ![Nephio guide image](/static/nephio-guide-image.png) ### What we want to achieve Using this architecture we can enable the following flow for our applications: 1. Developer A creates the new desired workload configuration 2. The porch component creates new branches in the corresponding git repositories for the edge-clusters for the changes 3. Developer B approves the changes 4. The configsync components in the edge-clusters update their corresponding App ![Nephio guide image 1](/static/nephio-guide-image-1.png) ## Set-Up ### Setting up the git repositories Nephio works with different repositories and supports multiple mechanisms for authentication. For the simplicity of this talk we’ll be using public repositories hosted on github: You can find our examples under [nephio-blogpost-master-cluster](https://github.com/SimonTheLeg/nephio-blogpost-master-cluster), [nephio-blogpost-edge-1](https://github.com/SimonTheLeg/nephio-blogpost-edge-1), and [nephio-blogpost-edge-2](https://github.com/SimonTheLeg/nephio-blogpost-edge-2). If you plan on using nephio’s config-sync component with private repositories and authentication, please refer to the official [config-sync documentation](https://cloud.google.com/anthos-config-management/docs/how-to/installing-config-sync#git-creds-secret). In your preferred git provider, create three repositories: nephio-master-cluster, nephio-edge-1, nephio-edge-2 ### Cluster Setup and Sizing We start by creating the three clusters we are going to use. For the purpose of this demo, we recommend sizing the master cluster to 4 vCPU and 8GB RAM in total and each edge-cluster to 2 vCPU and 4GB RAM. If you are using KKP, it will look similar to this: ![Nephio guide image 2](/static/nephio-guide-image-2.png) ### Installing nephio on the master-cluster Nephio is being installed using kpt. Kpt is a Kubernetes package and configuration management tool. It allows you to combine related Kubernetes manifests into a package and re-use them. Kpt is also used by nephio itself in order to deploy workload into the edge-clusters. At the time of writing, you **will need** **one of the beta versions of kpt**. Throughout this blogpost we are using the [v1.0.0-beta.37](https://github.com/GoogleContainerTools/kpt/releases/tag/v1.0.0-beta.37) release of kpt. Once you have kpt installed, we can move to the installation of nephio. Installing a package in kpt usually involves the following four steps: 1. Downloading a copy of the kpt package into your git repository ```bash # inside nephio-master git repository kpt pkg get https://github.com/nephio-project/nephio-packages.git/nephio-system@v1.0.1 # you can check that this creates a local copy of the full package inside your repository tree ``` 2. Applying any customizations to the local copy ```bash # In our case, we need an updated version of porch, but we also want a CRD, so we need to do the following cd nephio-system kpt pkg get https://github.com/nephio-project/nephio-example-packages/porch-dev cp porch/config-management-operator.yaml porch-dev rm -rf porch cd .. ``` 3. Initializing the package to be used with your cluster ```bash # with KUBECONFIG pointing to the nephio-master-cluster kpt live init nephio-system # this is going to create a resourcegroup.yaml file, which acts as our inventory less nephio-system/resourcegroup.yaml ``` 4. Deploying the package to your cluster ```bash # with KUBECONFIG pointing to the nephio-master-cluster kpt live apply nephio-system --reconcile-timeout=15m ``` After successful installation of nephio-system, we repeat the process for the nephio-webui package: ```bash # inside nephio-master git repository kpt pkg get https://github.com/nephio-project/nephio-packages.git/nephio-webui@v1.0.1 # with KUBECONFIG pointing to the nephio-master-cluster kpt live init nephio-webui kpt live apply nephio-webui --reconcile-timeout=5m ``` Afterwards we can port-forward to the nephio-webui using. ```bash kubectl -n nephio-webui port-forward svc/nephio-webui 7007:7007 ``` Now if you go to [localhost:7007](http://localhost:7007) on your machine, you should be able to see a UI similar to this: ![Nephio guide image 3](/static/nephio-guide-image-3.png) ### Adding our package repository to nephio In order for a package to be deployed using nephio, its repository needs to be registered. For this demo, we have prepared a [repo](https://github.com/SimonTheLeg/nephio-example-packages), which contains an envoy kpt package. You need to register it with your nephio installation using: ```bash # with KUBECONFIG pointing to the nephio-master-cluster kpt alpha repo register \ --namespace default \ --deployment=false \ https://github.com/SimonTheLeg/nephio-example-packages.git ``` ### Configuring nephio-master to edit edge-cluster repositories In order for the nephio-master to make changes to your edge-cluster repositories, it needs write permissions. In the case of Github, a [personal access token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens) with the `repo` scope is required. For additional authentication options for other git providers, please check the [kpt repository registration guide](https://kpt.dev/guides/porch-user-guide?id=repository-registration). This time we want to create our repository with the `--deployment` flag set to `true` to indicate to nephio that this repository is being used to track deployments: ```bash GITHUB_USERNAME=<your github username> GITHUB_TOKEN=<GitHub Personal Access Token> kpt alpha repo register \ --namespace default \ --repo-basic-username=${GITHUB_USERNAME} \ --repo-basic-password=${GITHUB_TOKEN} \ --create-branch=true \ --deployment=true \ <http url of your edge cluster-1 repo here> # and then we do the same for the edge-cluster-2 repo kpt alpha repo register \ --namespace default \ --repo-basic-username=${GITHUB_USERNAME} \ --repo-basic-password=${GITHUB_TOKEN} \ --create-branch=true \ --deployment=true \ <http url of your edge cluster-2 repo here> ``` Using the kpt cli has the advantage that it automatically creates all required secrets. Of course it is also possible to create the Repository CR and required secrets manually. In order to do so, please check out the [official kpt example](https://github.com/GoogleContainerTools/kpt/blob/main/porch/examples/config/git-repository.yaml). You should now have in total three repositories ```bash kubectl get repository # should return something similar to NAME TYPE CONTENT DEPLOYMENT READY ADDRESS nephio-blogpost-edge-1 git Package true True https://github.com/SimonTheLeg/nephio-blogpost-edge-1.git nephio-blogpost-edge-2 git Package true True https://github.com/SimonTheLeg/nephio-blogpost-edge-2.git nephio-example-packages git Package True https://github.com/SimonTheLeg/nephio-example-packages.git ``` ### Setting up config-sync in our edge-clusters Config-sync is the last component we will need to set-up. Config-sync runs inside an edge cluster and watches the corresponding git-repository for changes. After it has detected a change in its git repository, it automatically rolls out the change to its cluster. Since it is deployed in the edge cluster, we need to deploy a separate config-sync for each one. Once again we can use kpt to do so: ```bash # inside the edge-clusters-1 git repository kpt pkg get https://github.com/nephio-project/nephio-packages.git/nephio-configsync@v1.0.1 ``` This time, we need to make a modification, to point config-sync to our repository. In your favorite editor, edit `nephio-configsync/rootsync.yaml` and replace the `spec.git.repo` field to point to your edge-1 repository. ```diff --- a/nephio-configsync/rootsync.yaml +++ b/nephio-configsync/rootsync.yaml @@ -9,6 +9,7 @@ metadata: # kpt-merge: config-management-system/nephio-workload-cluster-sync spec: sourceFormat: unstructured git: - repo: https://github.com/nephio-test/test-edge-01 + repo: << url of your edge-1 repo >> branch: main auth: none ``` Afterwards deploy the package into the edge-1 cluster. ```yaml # with KUBECONFIG pointing to the edge-1-cluster kpt live init nephio-configsync kpt live apply nephio-configsync --reconcile-timeout=5m ``` Now we need to repeat the same process for the edge-2: ```bash # inside the edge-clusters-2 git repository kpt pkg get https://github.com/nephio-project/nephio-packages.git/nephio-configsync@v1.0.1 ``` This time, make sure `spec.git.dir` is pointing to the `edge-2` url: ```diff --- a/nephio-configsync/rootsync.yaml +++ b/nephio-configsync/rootsync.yaml @@ -9,6 +9,7 @@ metadata: # kpt-merge: config-management-system/nephio-workload-cluster-sync spec: sourceFormat: unstructured git: - repo: https://github.com/nephio-test/test-edge-01 + repo: << url of your edge-2 repo >> branch: main auth: none ``` ```bash # with KUBECONFIG pointing to the edge-2-cluster kpt live init nephio-configsync kpt live apply nephio-configsync --reconcile-timeout=5m ``` ## Deploying our package to the edge clusters As a demo, we will first deploy the package manually via the UI. This is a great way to show a typical flow and what happens behind the scenes. Afterwards we will be looking into a GitOps-friendly and multi-cluster way. This is going to use the PackageVariantSet CR. ### 1) Using the UI Go to Deployments ![Nephio guide image 4](/static/nephio-guide-image-4.png) Then to `Add Deployment` ![Nephio guide image 5](/static/nephio-guide-image-5.png) Now we are going to select `Create a new deployment by cloning a team blueprint`. This means that we are going to take the envoy package from our example packages and make a copy of it into our deployment repository. Additionally select `envoy` from the `Team Blueprint to Clone`, which is the package we want to deploy. ![Nephio guide image 6](/static/nephio-guide-image-6.png) You can leave the remaining steps unchanged and click on `Create Deployment` ![Nephio guide image 7](/static/nephio-guide-image-7.png) Now what is happening behind the scenes is that nephio is going to create a branch in your edge-clusters repository in order to draft the deployment. ![Nephio guide image 8](/static/nephio-guide-image-8.png) Afterwards click the `Propose` button in nephio to advance your draft to a proposal ![Nephio guide image 9](/static/nephio-guide-image-9.png) You will see that nephio now has created a new branch reflecting the proposal state of your change. ![Nephio guide image 10](/static/nephio-guide-image-10.png) For the purpose of this demo, approve your change. Of course, in a real-world scenario, the approval would be conducted by another developer. ![Nephio guide image 11](/static/nephio-guide-image-11.png) You can see that your changes have been merged into the `main` branch. ![Nephio guide image 12](/static/nephio-guide-image-12.png) This is going to trigger configsync, which now proceeds to roll-out envoy to the edge-cluster. ```bash # with KUBECONFIG pointing to the edge-1-cluster kubectl get pods -n envoy NAME READY STATUS RESTARTS AGE envoy-6867886d66-mnzdm 1/1 Running 0 28s ``` **Cleaning Up** At the time of writing, it is not possible to do the full deletion inside the UI. Therefore we have to manually search for the revision and trigger the deletion-proposal workflow: ```bash # with KUBECONFIG pointing to the nephio-master kubectl get packagerevision --field-selector spec.packageName=envoy,spec.revision=v1,spec.repository=<name of your repository for edge-1> # this should return a single PackageRevision, similar to this NAME PACKAGE WORKSPACENAME REVISION LATEST LIFECYCLE REPOSITORY nephio-blogpost-edge-1-1f1198bc626ef5f157fbfd8ea21e1e6ae471611f envoy v1 v1 true Published nephio-blogpost-edge-1 # Now we are going to set spec.lifecycle to DeletionProposed kpt alpha rpkg propose-delete <name of your Packagerevision> --namespace=default # Now we can delete the PackageRevision kpt alpha rpkg del <name of your Packagerevision> --namespace=default # For now we need to manually delete the folder inside edge-1 repository git rm -rf envoy git commit -m "cleanup envoy" git push ``` ### 2) Using PackavariantSets - a GitOps approach While the UI is great to demonstrate nephio’s regular deployment flow, it can become tedious when working with multiple edge clusters. This is where the PackageVariantSet comes in. A PackageVariantSet can be used to fan-out a deployment to multiple clusters. Inside the nephio-master git repository, create a file called `edge-clusters-packagevariantset.yaml` with the following contents: ```yaml # inside nephio-master git repository apiVersion: config.porch.kpt.dev/v1alpha2 kind: PackageVariantSet metadata: namespace: default name: edge-clusters spec: upstream: repo: nephio-example-packages package: envoy revision: v1 targets: - repositories: - name: <name of edge cluster 1 repository> - name: <name of edge cluster 2 repository> ``` Apply it to the nephio-master cluster: ```bash # with KUBECONFIG pointing to the nephio-master kubectl apply -f edge-clusters-packagevariantset.yaml ``` Now you should see how a draft branch has been created inside each of your edge-cluster repositories. ![Nephio guide image 13](/static/nephio-guide-image-13.png) ![Nephio guide image 14](/static/nephio-guide-image-14.png) From there on you can follow the regular approval flow from the previous section to roll-out your changes. ## Outlook This was a simple demo to illustrate the concepts behind nephio and illustrate its capacities. It can be extended to more complex interconnected workloads. In fact, nephio is designed to accommodate complex workloads like 5G core deployments. For a full example which deploys free5GC using nephio, please refer to the official [nephio user-guide](https://github.com/nephio-project/docs/blob/main/user-guide/exercises.md). Additionally, this blogpost largely focuses on a strict 4-eye principle for every package. With additional git-automation, it is possible to streamline the process for large installations. --- ## Managed Kubernetes as a Service in the Bioinformatics Cloud - **URL:** https://www.kubermatic.com/resources/managed-kubernetes-as-a-service-in-the-bioinformatics-cloud/ - **Date:** 2026-06-23 - **Description:** Kubermatic & SVA enable simple and fast provisioning of Kubernetes clusters in self-service for bioinformaticians. Read how! # Managed Kubernetes as a Service in the Bioinformatics Cloud Partner Success Story With Kubermatic’s products, SVA has enabled simple and fast provisioning of Kubernetes clusters in self-service for bioinformaticians ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ![SVA logo](/static/sva.svg) ![Berlin Institute of Health logo](/static/bih-logo.svg) The mission of the Berlin Institute of Health (BIH) is medical translation: findings from biomedical research are transferred into new approaches for personalized prediction, prevention, diagnostics and therapy; conversely, observations in everyday clinical practice lead to new research ideas. To this end, the BIH, as a translational research unit at Charité, is establishing a comprehensive translational ecosystem, focusing on a cross-organ understanding of health and disease and promoting a translational cultural change in biomedical research. BIH was founded in 2013 and is 90 percent funded by the Federal Ministry of Education and Research (BMBF) and ten percent by the State of Berlin. The founding institutions Charité - Universitätsmedizin Berlin and Max Delbrück Center were independent members of BIH until 2020. Since 2021, BIH has been integrated into Charité as a so-called third pillar, and the Max Delbrück Center is a privileged partner of BIH. ## Challenge ### Providing Kubernetes clusters for bioinformaticians The de.NBI cloud environment at the Berlin Institute of Health has been established since 2017 and provides resources for bioinformaticians as an Infrastructure as a Service. Users are able to independently create a complete environment with virtual instances, storage as well as network and load balancer within the scope of their project, either via user interface or automation. Now that containers and Kubernetes are no longer just a trend, but have really arrived in IT and thus also in bioinformatics, the demand from bioinformaticians to also operate such Kubernetes clusters on the de.NBI Cloud at the Berlin site is increasing. Thanks to the existing options within the de.NBI Cloud, it is easily possible to provision a Kubernetes cluster yourself within a short time. However, the management, e.g. the update of such a cluster, also requires a certain amount of time, which the bioinformaticians cannot devote to their actual research work. At the same time, the operators of the de.NBI Cloud are interested in offering users the simplest possible user experience and standardized services that generate added value and not additional effort for the projects. ![Scheme structure icon](/static/scheme-icon-white.svg) ![Atom icon](/static/atom.svg) ## Solution ### Kubermatic Kubernetes Platform **Together with the cloud team at the Berlin Institute of Health at Charité, the SVA experts first evaluated various approaches and solutions and the decision was ultimately made in favor of the Kubermatic Kubernetes Platform (KKP). With KKP, it was possible to build a central control plane that can be scaled flexibly and then also connect different cloud providers - in this case, the OpenStack-based cloud at BIH.** ![Bulb lamp](/static/bulb-lamp.png) The architecture of KKP is itself based on a Kubernetes cluster, which is integrated into the existing OpenStack environment by means of so-called cloud controllers. With KubeOne, Kubermatic offers a solution to initially create and manage this base cluster. This enables the KKP platform administrators to configure the underlying infrastructure in a fully automated way, e.g. to dynamically add further resources required for the control plane. ![Phone and laptop](/static/phone-and-laptop.png) The end users (bioinformaticians) only see the KKP user interface as a product, into which they log in with the existing OpenID Connect-based authentication to provision Kubernetes clusters directly into their assigned project within OpenStack. A key advantage is that end users do not need to have any knowledge of the underlying infrastructure, but simply choose how many resources they need and which node types (e.g. GPU, high memory) should be available in their cluster. Even updates to the clusters can be carried out by the end users with a click. ![People group hands](/static/people-group-hands.png) The SVA experts were able to successfully accompany the project from the creation of the concept, through the set-up and integration into the existing OpenStack environment, to operational readiness. SVA continues to support de.NBI in the further development of the environment and works with the customer as a joint "cloud team". ![Double quotes image](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==) A decisive advantage is that the Kubernetes control plane, i.e. the masternodes are not set up as three virtual machines for each cluster, but are hosted centrally. **The administration of the clusters can be done completely by the users after the projects have gained access to KKP, which is extremely end-user friendly.** ***Harald Wagener, Group Leader Cloud, AG Eils, BIH*** ![Charité building](/static/charite-building_hu_85fc21296621f52a.png) --- ## Meet KKP 2.23: The most Cost-Effective Kubernetes-as-a-Service - **URL:** https://www.kubermatic.com/blog/kkp-2-23-your-gateway-to-the-most-cost-effective-kubernetes-as-a-service/ - **Date:** 2026-04-30 - **Description:** KKP 2.23 comes with new features that make multi-cloud Kubernetes management easier, convenient & secure. - **Categories:** Products - **Tags:** KKP - **Authors:** Csenger Szabo Welcome to the world of multi-cloud Kubernetes management excellence! We’ve proud to announce KKP 2.23 which again makes the management of containerized workload in your bare-metal, edge and multi-cloud environment even easier. ## Local Kubermatic Kubernetes Platform environment for experiments (Technology Preview) Using KKP is so easy that you could even teach your grandma how to spin up new Kubernetes clusters and manage them afterwards. However, installation might be tricky, because of the complexity of the underlying infrastructure that enables you to consume 20X less resources for management components of all of your clusters. If you have already been curious about the capabilities of KKP, but have always been afraid of the high-level entry threshold that the installation takes, then we’ve got you covered from now on! We are introducing the **kubermatic-installer local** command for spinning up a local KKP environment. It avoids the need of setting up certificates and DNS for your KKP installation, and it also won’t need you to build up multiple Kubernetes clusters as prerequisites for the master and seed components. You can just easily run a KKP installation locally. Of course, because of its nature it is not meant to be used for production environments, but it’s an awesome way, for example, to check out new KKP features quickly for development purposes. *Note: this feature is still considered as an experimental one, so it’s in a Technology Preview state.* ## Importing KubeOne clusters into Kubermatic Kubernetes Platform Our popular open-source product, KubeOne helps you manage the whole Kubernetes cluster lifecycle with its simple CLI tool. Many organizations, having just a few clusters, use KubeOne for making their daily job easier. Imagine the scenario, when you have a smaller infrastructure. In the beginning you might have started with creating a few clusters with KubeOne, since it provided a handy solution for managing those first few clusters. Later, as the infrastructure was growing, you started having a need for a more complex solution, where your whole fleet can be managed efficiently. So you installed KKP Community Edition, or decided [to upgrade to Enterprise Edition](/contact-us/), because you might need more advanced solutions, like multiple seeds or resource quotas for your different teams. In this latter scenario, you probably want to still use your KubeOne clusters that have been created earlier. With our external cluster importing feature, you can easily inhouse your KubeOne clusters into KKP’s fleet management platform. It was already possible to do with clusters running on AWS, Azure and Google Cloud. We extended the list of providers where KubeOne clusters can be pulled in from. The new providers are: DigitalOcean, Hetzner, VSphere, Openstack. ## API token authentication for VMware Cloud Director This latest feature enables cluster administrators on VMware Cloud Director (VCD) providers with enhanced authentication capabilities. With the introduction of API Access Token Authentication, users can now securely authenticate their automation solutions. This brings convenience and security together by allowing administrators to choose between password-based authentication or API token authentication, based on their preferences and requirements. KKP basically lets you select if you want to provide “User Credentials” or “Application (or API Token) Credentials” during Cluster creation and preset definition as well. This addition holds value for various use cases. Unlike passwords that often expire and require updates and human interaction, API tokens can offer a persistent and reliable authentication method. Also, in environments that enforce Multi-factor Authentication (MFA, like 2FA) for user logins, you can continue to leverage the full potential of KKP with your VCD provider without any interruptions. ## Kubernetes 1.27 arrives We deliver the newest version of Kubernetes within Kubermatic Kubernetes Platform, so that you can leverage all the new features and enhancements in your user clusters. Check out here what’s new in Kubernetes 1.27: https://kubernetes.io/blog/2023/04/11/kubernetes-v1-27-release/ ## Kubermatic Kubernetes Platform always keeps the pace KKP 2.23 delivers a huge amount of updates to components, making sure its users get all improvements delivered from upstream. If you are wondering what components were updated to which version, please take a look at the list of our release notes: https://docs.kubermatic.com/kubermatic/v2.23/release-notes/ ## It’s time to launch now! 🚀 If you still want to look around about what’s new or what features we have, check our KKP 2.23 documentation here: https://docs.kubermatic.com/kubermatic/v2.23/ When you’re updating from KKP 2.22 to KKP 2.23, our guidance will help you through: https://docs.kubermatic.com/kubermatic/v2.23/installation/upgrading/upgrade-from-2.22-to-2.23/ If you are just starting with experimenting KKP for the first time and you don’t have an active installation, you can download the v2.23 installer binaries of our community editions here: https://github.com/kubermatic/kubermatic/releases/tag/v2.23.0 Here you can also find our guide for the whole installation process: https://docs.kubermatic.com/kubermatic/v2.23/installation/ If you don’t want to use it in production, just testing and experimenting, try our brand-new local installation feature: https://docs.kubermatic.com/kubermatic/v2.23/installation/local-kkp-installation **If you are interested in the Enterprise Edition with extended features like multiple seed clusters, resource quotas or edge capabilities, [then contact us and let’s talk](/contact-us/)!** --- ## Kubermatic Sponsors CNCF Sandbox Application for kcp - **URL:** https://www.kubermatic.com/blog/kubermatic-sponsors-cncf-sandbox-application-for-kcp/ - **Date:** 2026-04-30 - **Description:** Kubermatic proudly sponsors the CNCF Sandbox Application for kcp, the Control Plane of the Future. Explore the innovative strides towards cloud-native infrastructure management. - **Categories:** Company, Community - **Tags:** Open Source Projects, Announcements - **Authors:** Sebastian Scheele, Marvin Beckers When building a scalable, multi-tenant platform like Kubermatic Kubernetes Platform, we think a lot about APIs. How users programmatically interact with our platform is a central key consideration and defines a significant part of the user experience. We have been leveraging custom resources (as defined in CRDs) from the inception of our platform. With recent KKP releases, we brought more direct usage of our custom resources to KKP users to further automate cluster management and integrate KKP into an existing platform stack based on standard Kubernetes mechanisms. However, we heard from our users that they hope we push these concepts even further and bring even more multi-tenancy capabilities to our platform. We experimented with multiple approaches and built tools like [Bulward](https://github.com/kubermatic/bulward). During development we realized that the problem we are solving is not specific to Kubermatic and its products. As a company with a strong Open Source and community focus we were looking around if we could not find like-minded people and companies who are trying to solve the same problem and join forces. Searching for a suitable solution, we found [kcp](https://kcp.io). ## What is kcp? kcp extends the Kubernetes API we all know and love by adding advanced isolation and API management concepts to the core Kubernetes experience. It is not a fork but a citizen of the Kubernetes ecosystem, built upon the latest Kubernetes releases and simply optimizing it for the use case in question --- Massive scalability, API management, strong multi-tenancy. kcp decouples the high quality of Kubernetes' API concepts and its purpose as container orchestrator and allows building API platforms without the workload management parts. It also introduces a new multi-tenancy concept called "Workspaces" that helps enforce boundaries between different teams or organizations using the same kcp instance. Workspaces are essentially "logical" Kubernetes clusters, each of them acting like a dedicated Kubernetes API server. This means that resources are not shared across workspaces and the types of resources differ from workspace to workspace. kcp's API exports allow workspaces to consume a set of APIs and is a crucial building block to building an as-a-service experience. ### Diving into Workspaces If you are interested in trying out kcp, [a quickstart guide](https://docs.kcp.io/kcp/main/#quickstart) is available on the project website. Taking kcp for a test drive is really easy and can help understand what kcp actually offers. Let’s quickly explore workspaces together, using a kubectl plugin provided by kcp --- When you start kcp from scratch only one workspace exists, and it is called "root". This is --- as the name suggests --- the root of our workspace tree, since workspaces can be arranged in a hierarchy (i.e. you can create workspaces within workspaces and they become children of that workspace). Creating new workspaces (if you have the necessary permissions) is as easy as: ```sh $ kubectl ws create kubermatic --type=organization --enter Workspace "kubermatic" (type root:organization) created. Waiting for it to be ready... Workspace "kubermatic" (type root:organization) is ready to use. Current workspace is "root:kubermatic" (type root:organization). ``` A few workspaces later, the workspace tree could look something like this: ```sh $ kubectl workspace tree . └── root └── kubermatic ├── department-a │ ├── team-a │ ├── team-b │ └── team-c └── department-b ├── team-a └── team-b ``` Switching back and forth between workspaces is as easy as passing their paths to the kubectl plugin: ```sh $ kubectl workspace root:kubermatic:department-a:team-b Current workspace is "root:kubermatic:department-a:team-b". $ kubectl workspace root:kubermatic:department-b:team-a Current workspace is "root:kubermatic:department-b:team-a". ``` The important bit --- and this is where the power of kcp starts to shine through --- is that each workspace acts like a separate Kubernetes API to the user accessing it. This means creating namespaces, CustomResourceDefinitions, or other kinds of resources in one of the team workspaces will only affect that workspace and custom resources created by CRDs will be confined to that specific workspace. That being said, each workspace can be accessed by normal kubectl --- the plugin is only a helper to discover API endpoints. For managing API resources across workspaces, kcp offers `APIExports`/`APIBindings`. The kcp documentation has [a quickstart](https://docs.kcp.io/kcp/main/concepts/quickstart-tenancy-and-apis/) on the whole process of managing APIs at scale and we recommend walking through it to get a feeling for what is possible with it. ## Community Governance In May 2023, the previous stewards of kcp decided to step down from their role and started the search for a new home for kcp. Kubermatic, among other organizations and individuals, had the idea to continue kcp in a fully community-driven approach. As part of the new community new community governance was established and Sebastian Scheele became one of the three initial maintainers after the governance transfer. You can find the current governance document here. We are thrilled to be part of the community that is now pushing kcp ahead. One of the first big challenges for the project was moving to a new Continuous Integration (CI) infrastructure to resume testing and validating contributions. Kubermatic stepped up and provided a new Prow instance that is used for CI/CD in the kcp-dev GitHub organization. Kubermatic is proud to sponsor such an important project by providing the necessary infrastructure. Just a few days ago, the first kcp release (0.20.0, [available on GitHub](https://github.com/kcp-dev/kcp/releases/tag/v0.20.0)) under the new governance model has been released. It is one of the biggest kcp releases since its start and proves to us that the project is alive and kicking. ## CNCF Sandbox Application We strongly believe kcp is the control plane of the future and enables building cloud native platforms that cannot be rivaled in scalability and user experience. Because of that, Kubermatic is proud to sponsor [the application to let kcp join the CNCF Sandbox](https://github.com/cncf/sandbox/issues/47) and become a part of the Cloud Native landscape, unlocking organizations' ability to build and manage large-scale APIs that feel like you are operating a Kubernetes cluster without the overhead of actually running Kubernetes. We hope this proposal will be accepted and will help foster adoption of and contributions to kcp. If you are interested in joining the growing kcp community, join us in the #kcp-dev Slack channel on [the Kubernetes Slack](https://kubernetes.slack.com) or on [the bi-weekly community calls on Thursdays](https://groups.google.com/g/kcp-users?pli=1). ## About Kubermatic Kubermatic empowers organizations worldwide to fully automate their Kubernetes and cloud native operations across multi-cloud, edge and on-prem As the top European committer to the Kubernetes project, Kubermatic is a trusted provider of enterprise-grade software solutions, professional services, and support to help organizations safely navigate and accelerate their cloud native transformation. With the Kubermatic Kubernetes Platform (KKP), organizations can easily operate thousands of Kubernetes clusters on any infrastructure, empowering them to achieve their goals with greater speed and efficiency. Renowned enterprises such as Lufthansa, Bosch, Siemens, and T-Systems rely on Kubermatic to lead their cloud native journey. Headquartered in Hamburg, Germany, Kubermatic is well-positioned to support organizations worldwide in achieving their digital transformation goals. Find us at: [www.kubermatic.com](https://www.kubermatic.com) Follow us on: [Twitter](https://twitter.com/Kubermatic) [LinkedIn](https://www.linkedin.com/company/kubermatic) [Github](https://github.com/kubermatic) --- ## Industry Edge - **URL:** https://www.kubermatic.com/products/kubermatic-kubernetes-platform/industry-edge/ - **Date:** 2026-03-30 - **Description:** Explore kubernetes for edge computing to overcome data management & security challenges. Get your business ready for enhanced performance. # Harness Kubernetes and Edge Computing to Grow Your Business Leverage Kubernetes to stay ahead of your competition [Book a demo](/demo/) [Read the brief](/static/Solution_Brief_KKP_Manufacturing_Edge.pdf) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Slow Maintenance Hindering your Business Growth? ### Accelerate maintenance and reduce operational costs Outdated maintenance strategies, reactive to issues as they occur or following a rigid schedule, can result in unnecessary repairs, unexpected machine failures, and escalating costs. Leap into the future of industrial predictive maintenance with Kubernetes at the edge — more efficient, more effective, and more reliable. ![](/static/sheets-icon-pink-grad.svg) ### Empower data management Kubernetes at the edge efficiently manages the massive data volumes from industrial machines by processing information locally, thereby lightening the load on your network. ![](/static/clock-gold-pink.svg) ### Expedite responses Delays in predictive maintenance can be costly. With Kubernetes at the edge, say goodbye to latency issues. Experience near real-time data processing and faster response times. ![](/static/hscheme-icon-pink-grad.svg) ### Simplify operations Predictive maintenance software can be complex. Kubernetes simplifies this complexity with its powerful orchestration capabilities, making container management a walk in the park. ## Fast track business growth with Kubernetes for Edge ![](/static/light-bulb-grad.svg) ### Accelerate maintenance & shrink operational costs - Master massive data handling and local processing - Enjoy lightning quick response times ![](/static/console-grad.svg) ### Banish Bad Quality - Enable instant anomaly detection and rapid corrective actions - Eliminate delays of cloud based analysis ![](/static/ship-wheel-grad.svg) ### Revel in unmatched security & interoperability - Seamlessly scale and adapt to changing demands - Process data on-premise, reduce exposure to potential threats ## Eliminate Bad Quality ### Use Remote Monitoring for Optimized Efficiency Legacy approaches to quality control and remote monitoring are often tedious, susceptible to human mistakes, and deficient in delivering real-time responses. Experience real-time insights, uninterrupted operations, streamlined data management, scalability, data security, and interoperability like never before. ![](/static/rocket-icon-pink-grad.svg) ### Real time insights, instant action Quality control and remote monitoring demand swift responses. Kubernetes at the edge empowers you with real-time data processing, enabling instant anomaly detection and rapid corrective actions without the delays of cloud-based analysis. ![](/static/planet-hand-icon-pink-grad.svg) ### Uninterunpted operations, anywhere Poor network connectivity in remote manufacturing facilities can cripple remote monitoring efforts. With Kubernetes at the edge, your operations remain seamless and uninterrupted, even in the face of unstable network connections. ![](/static/gear-icon-pink-grad.svg) ### Streamlined data management Massive volumes can overwhelm traditional systems. Kubernetes at the edge solves this challenge by processing data locally, reducing the strain on your network infrastructure. Watch now: [Delivering operations despite security breaches!](/resources/running-kubernetes-in-a-manufacturing-line/) ## There's more ![](/static/scalability-changing-business.jpg) ### Scalability made easy Manufacturing operations are dynamic, requiring scalability to match fluctuating demands. Kubernetes' container orchestration capabilities empower you to scale resources seamlessly, efficiently adapting to changing requirements. ![](/static/network-security-system.jpg) ### Enhanced data security Data security is paramount, especially when transmitting sensitive information to the cloud. By leveraging Kubernetes at the edge, more data processing takes place on-premises, reducing exposure to potential threats. Kubernetes's built-in security features further fortify data protection. ![](/static/hot-jigsaw-puzzle.jpg) ### Embrace interoperability Diverse devices and systems are common in manufacturing environments. Kubernetes at the edge embraces this diversity, with its vast ecosystem and plugin support, ensuring smooth interoperability and seamless integration of your monitoring solutions. ## Guaranteed Uninterrupted Edge Operations with KKP ### Choose KKP — the perfect partner for streamlined, powerful, and secure edge operations. Your partner in eliminating unplanned downtimes. ![](/static/point-hand-icon-white.svg) ### Exceptional ease of use Designed with users in mind, KKP minimizes cognitive load for developers and operators. Change and adapt your systems as needed without any hindrance, for a truly seamless experience. ![](/static/consistency-icon-white.svg) ### Unrivaled deployment flexibility KKP leverages a declarative approach for managing both software and hardware, promoting agility and efficiency. Our commitment to GitOps and API-first approach enables robust, flexible operations. ![](/static/centralized-icon-white.svg) ### Boundless availability KKP goes where you go. From the cloud to data centers, and right to the edge, KKP delivers consistent performance across all infrastructures. ![](/static/heart-icon-white.svg) ### Unparalleled density and resilience With KKP, resilience isn't an afterthought — it's built into our design. Thanks to our multiple seed clusters, management is independent from workloads, resulting in unmatched density and resilience. ![](/static/exchange-icon-white.svg) ### Integrated security and observability Enjoy the peace of mind that comes with an integrated security and observability solution. KKP combines these critical aspects into one flexible, open-source solution for a secure, transparent operating environment. Want to Know More? [Explore further](/products/kubermatic-kubernetes-platform/edge/) ## Navigating the Future The union of AI/ML and Kubernetes on the edge equips manufacturing lines with a new level of predictive maintenance, quality control, and operational efficiency. AI-driven maintenance systems anticipate equipment malfunctions before they happen, reducing downtime and operational costs. Advanced ML algorithms scrutinize every step of the production process for quality control, ensuring unparalleled product consistency. ### Reducing latency By processing data close to its source, i.e., the vehicles, Kubernetes on the Edge ensures swift and real-time decisions. ### Utilizing efficient bandwidth Edge deployment allows for local data processing, significantly reducing the amount of data to be transferred to the cloud, thereby optimizing bandwidth usage. ### Improving reliability Kubernetes' distributed architecture ensures even if one part of the network fails, the system operates smoothly, providing a reliable network backbone for AVs. --- ## Why Securing Kubelet API is Critical for K8s Security? - **URL:** https://www.kubermatic.com/resources/why-securing-kubelet-api-is-critical-for-k8s-security/ - **Date:** 2023-05-22 - **Description:** This lightning talk explores the importance of securing the Kubelet API. # Why Securing Kubelet API is Critical for K8s Security? ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Koray Oksay's Lightning Talk at Cloud Native Rejekts EU 2023 Kubelet is a crucial component of Kubernetes that runs on each node and is responsible for managing container runtime, monitoring container health, and reporting node status to the control plane. However, this critical component is often overlooked regarding security, leaving the cluster vulnerable to potential attacks. **Speaker: Koray Oksay, Consultant / SRE / Trainer at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Rejekts 2023: Ephemeral Containers: Running Go Debugger in Kubernetes - **URL:** https://www.kubermatic.com/resources/ephemeral-containers-in-action-running-a-go-debugger-in-kubernetes/ - **Date:** 2024-10-16 - **Description:** Ephemeral containers are an amazing recent feature in Kubernetes with great potential. We will explore that potential by running a live debugger session alongside an application pod and debug it remotely. # Ephemeral Containers in Action - Running a Go Debugger in Kubernetes - Rejekts 2023 ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Marvin Beckers' Talk at Cloud Native Rejekts EU 2023 Ephemeral containers are an amazing recent feature in Kubernetes with great potential. We will explore that potential by running a live debugger session alongside an application pod and debug it remotely. The modern observability stack has transformed the way you troubleshoot issues in a microservice environment. Some situations however ask for investigation of a single application pod that seems to be misbehaving. Ephemeral containers provide a way to attach to a seemingly problematic pod without restarting it. This allows developers to observe an issue in a live or staging environment running on top of Kubernetes. We will discuss the practicality of launching a Go debugger (Delve) within an ephemeral container to remotely debug an application both on the CLI and in VS Code, highlighting the requirements and possible limitations one might encounter when trying to set up a similar troubleshooting routine. As part of that, we will explore the API for ephemeral containers and the current implementation in kubectl. While the talk will use Go and Delve as an example, the considerations and steps presented are of universal importance to running a debugger for your language stack of choice. **Speaker: Marvin Beckers, Senior Software Engineer at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Migrating Kubernetes CI Jobs to AWS - **URL:** https://www.kubermatic.com/resources/migrating-kubernetes-ci-jobs-to-aws/ - **Date:** 2023-05-22 - **Description:** In this talk, Marko and Patryk will talk about how the new Prow build cluster running on AWS looks like and what is the current status of the cluster, together with some common issues and lessons learned along the way. # Migrating Kubernetes CI Jobs to AWS ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Marko Mudrinić and Patryk Przekwas' Talk at the Kubernetes Contributor Summit 2023 in Amsterdam Kubernetes project uses Google Cloud for all its needs since the project’s inception. This includes serving binaries, packages, images, but also running all sorts of tests and CI/CD (Prow). However, Kubernetes is becoming a bigger and bigger project, so costs are skyrocketing and we need to reduce and distribute them. Other cloud providers, such as AWS, joined the efforts and provided credits to the Kubernetes project. Now we need to find a way to utilize those credits and one of the ways is to make our CI jobs cloud-agnostic and run them on other providers. In this talk, Marko and Patryk will talk about how the new Prow build cluster running on AWS looks like and what is the current status of the cluster. They’ll also talk about plans for migrating existing jobs, as well as how you, as a subproject maintainer, can help us with the process. They’ll also talk about some common issues and lessons learned along the way. **Speakers: Marko Mudrinić and Patryk Przekwas, Software Engineers at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## SIG Release: Ensuring Kubernetes Stability & Security - **URL:** https://www.kubermatic.com/resources/how-sig-release-makes-kubernetes-releases-even-more-stable-and-secure/ - **Date:** 2024-03-21 - **Description:** In this session, Verónica and Marko will show how Kubernetes influenced many other projects in the community by providing them with tooling that they can use to release their projects securely. # How SIG Release Makes Kubernetes Releases Even More Stable & Secure ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Marko Mudrinić and Verónica López's Talk at KubeCon + CloudNativeCon EU 2023 SIG Release is one of the largest Kubernetes Special Interest Groups, responsible for delivering Kubernetes to millions of users. To accomplish that, individual contributors invest their time in developing various tools and libraries and ensuring that our release pipeline is as safe as possible. In this session, Verónica and Marko will show how Kubernetes influenced many other projects in the community by providing them with tooling that they can use to release their projects securely. They will highlight our two major efforts in 2023: moving packages from Google infra to the community-provided infra and migrating to the new image registry. Finally, they will talk about how you can join SIG Release and our efforts to make Kubernetes releases better. Watch and see what it means for you as an end user, and how you can build upon our efforts as a Kubernetes subproject maintainer. **Speakers: Marko Mudrinić, Software Engineer at Kubermatic & Verónica López, Software Engineer at PlanetScale.** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Build, Run and Monitor in Kubermatic Kubernetes Platform - **URL:** https://www.kubermatic.com/products/kubermatic-kubernetes-platform/features/ - **Date:** 2026-03-13 - **Description:** Automate kubernetes deployment with Kubermatic Kubernetes Platform for multi-cluster kubernetes management on multi-cloud, on-premise and edge environments. # Kubermatic Kubernetes Platform Quickly achieve cloud native transformation without the burden of infrastructure management [Get your free demo](/demo/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) - [Introduction](/products/kubermatic-kubernetes-platform/) - Features ## Freshly Released ![KKP 2.29 is out!](/static/meet-kkp-2-29-the-next-step-in-making-kubernetes-ai-ready_hu_9f0de6051ad90ce7.png) ## [Meet KKP 2.29: The next step in making Kubernetes AI-ready](/blog/meet-kkp-2-29-the-next-step-in-making-kubernetes-ai-ready/) Discover what’s new in KKP 2.29: Making Kubernetes AI-ready, OpenStack integration, and improved security. [Read](/blog/meet-kkp-2-29-the-next-step-in-making-kubernetes-ai-ready/) ## Latest Features - ### [AI Power for Infrastructure Operation](/solutions/automate-with-ai/) KKP leverages AI-driven automation with **AI Kit** for seamless deployment of AI, GenAI, and LLM workloads at scale, optimizing performance for both CPU and GPU. Additionally, **K8sGPT** is integrated as a default application and CLI tool within the web terminal, enhancing cluster debugging by bringing AI-powered insights closer to human understanding. Explore - ### [Automated Kubernetes Backups](/solutions/kubernetes-backups/) Leveraging Velero and the Kubernetes API, it ensures seamless backup, recovery, and migration across on-premises and cloud environments. With the latest **KKP update**, users can now restore cluster backups to a completely different KKP instance, providing greater flexibility for disaster recovery, environment transitions, or planned migrations. Explore Vanilla Kubernetes Multi-tenant Architecture Identity and Access Management Automated kubernetes lifecycle management Backup & Recovery Artificial Intelligence and GenAI for Infrastructure Operation Free choice of infrastructure stack Multi-cloud abstraction layer Kubernetes Application Management Self-service portal Kyverno Integration for Policy Management CNI: Choose or Bring your Own Single Platform to Manage Virtual Machines on Bare-Metal Complete Control Over Hybrid & Edge Deployments Dual Stack Support Kubernetes Monitoring Tools Full Lifecycle Management Integrated AddOn Controller Whitelabel with KKP Platform communication ### Vanilla Kubernetes - 100% kubernetes compliant. - Kubernetes version compliance within 4-6 weeks. - Support for Kubernetes 1.32 - 1.35, enhancing security and stability. ### Multi-tenant Architecture - Separate cloud providers and preset environments by organizational units. - Datacenter separation – decide where the data is stored. - Multi-cluster separation lowers effort for in-cluster policy enforcement. - Support for Static Labels on Clusters that allows the tagging of immutable metadata to clusters, facilitating more consistent management across multi-cluster environments. ### Identity and Access Management - Streamline authentication and access control, user and team management, enterprise security and operational observability. - Deploy securely provisioned clusters with blueprints and presets to keep developers within company policies. - Audit Logging Webhook Backend for improved security and compliance monitoring, which allows routing of audit logs to external systems. - Enable or disable the "Encryption at Rest" feature on a running user cluster directly from the dashboard. ### Automated kubernetes lifecycle management - Provision, scale, update, and clean up of clusters with just an API call. - Automatic roll out and roll back of upgrades. - Templatized workflows for repetitive tasks. - Migration from Machine-Controller Userdata to OSM, which improves the management of OS-level configurations, resulting in smoother operations. ### Backup & Recovery - Centralized multi-cluster and multi-cloud backup handling- select from daily, weekly, monthly or customized as backup options. - Customizable backup locations - Multiple backup destinations from the UI Admin Panel. - Gzip Support for ETCD Snapshots, which optimizes backup storage by reducing the size of snapshots, speeding up the process. - Enhanced Cluster Backup: Restore to different KKP instances for flexible recovery and migration. - Upload backup files directly from the UI to your configured S3 bucket for faster recovery workflows. - Label backup objects with their source to simplify organization and retrieval. ### Artificial Intelligence and GenAI for Infrastructure Operation - Next Level Cluster Debugging with K8sGPT which has been integrated to KKP as a default application and also to the web terminal feature as a CLI tool. - Effortless Nodes Management with NVIDIA GPU's and other specialized devices through Kubernetes' device plugin framework. - Flexibility, Automation & Increased Efficiency: AI-Native Infrastructure Platform, specifically designed to utilize AIOps to ensure optimal operator and end-user experiences. - AI Kit in KKP: Effortlessly deploy AI, GenAI, and LLM workloads with optimized performance for both CPU and GPU workloads. AI Kit simplifies running inference and fine-tuning machine learning models, supports multi-modal models, and provides air-gapped environment compatibility. - Dynamic Resource Allocation (DRA) is enabled to optimize resource utilization and workload performance. ### Free choice of infrastructure stack - Native support of AWS, Azure, GCP, DigitalOcean, Alibaba Cloud, OpenStack, VMware, Bare Metal Provider Support with Tinkerbell Integration, and more. - Fast switching between clouds / on-prem by using one common default layer. ### Multi-cloud abstraction layer - Abstract cloud dependencies from the cluster consumer using preset environments. - Centralized multi-cluster Logging, Monitoring, and Consumption Metering. ### Kubernetes Application Management - Deploy any third-party application on a user cluster, with a few clicks. - After installation, applications can be reconciled to ensure reliability. - Default Applications Management for automatically installing preconfigured applications on new clusters, ensuring consistency and reducing setup time. - Cluster Autoscaler as an Application for flexible scaling management. ### Self-service portal - Deliver Kubernetes-as-a-Service to end users. - Powerful & intuitive dashboard to visualize Kubernetes deployment. - Kubelogin kubectl plugin support simplifies authentication workflows. - Application Catalog supports dynamic version upgrades independent of KKP's release cycle. ### Kyverno Integration for Policy Management - Kyverno integration provides a Kubernetes-native way to define and enforce policies. - Platform Admins and Project Owners can manage policies directly as Kubernetes resources. - Default policy templates and UI support make it easy to get started with governance. ### CNI: Choose or Bring your Own - Users can choose between the two most popular CNIs: Canal and Cilium. - Additionally, users can simply add and manage a CNI of their choice. - Allow eBPF Proxy Mode When CNI is None, which adds flexibility for handling network traffic when a CNI is not needed. ### Single Platform to Manage Virtual Machines on Bare-Metal - Eliminate the need to run dedicated platforms to manage virtual machines on-premise. - Provision multiple kubernetes clusters on VMs on-premise with KubeVirt Cloud provider. - Enhanced multi-tenancy support with a new mode that allocates all KKP resources (e.g., VMs, volumes, load balancers) within a single KubeVirt namespace. This approach improves management and isolation, allowing multiple KKP instances to run on a shared KubeVirt infrastructure. - Support for vCPU and CPU allocation ratio configuration for KubeVirt VMs for better resource utilization. ### Complete Control Over Hybrid & Edge Deployments - Operating System Manager (OSM) is responsible for creating and managing the required configurations for worker nodes in a Kubernetes cluster. - Support for Enabling Cloud Drive on OpenStack VMs and Supporting VM Groups in vSphere for enhanced VM management in edge or hybrid environments. ### Dual Stack Support - Kubernetes resources can have both an IPv4 and IPv6 address. ### Kubernetes Monitoring Tools - Monitor health and resource consumption with built-in Prometheus and Grafana. ### Full Lifecycle Management - Upgrade your control plane and nodes without disruption and roll back as you need. ### Integrated AddOn Controller - Easily add any additional software, configuration, or policy into clusters. - Automate Addon Maintenance, which ensures regular updates to add-ons without manual intervention, enhancing security. ### Whitelabel with KKP - Customize Kubermatic Kubernetes Platform to your brand and needs. ### Platform communication - Admin Announcement Feature: Broadcast messages for maintenance and updates. > **If it works with kubernetes, it works with KKP!** --- ## How Interhyp and Kubermatic Achieved a Faster Time-to-market - **URL:** https://www.kubermatic.com/customers/interhyp/ - **Date:** 2026-06-23 - **Description:** Interhyp AG, Germany's largest private construction financing broker, teams up with Kubermatic to slash time to market from 2 days to 1 hour. Here's how! # How Interhyp and Kubermatic Achieved a Faster Time-to-market Kubermatic and Interhyp Team Up to Slash Time-to-Market from 2 Days to 1 Hour ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ![Interhyp logo](/static/interhyp.svg) Interhyp AG, Germany's largest broker for private construction financing, has been providing top-quality financial services for over 20 years. With a million satisfied customers to its name, Interhyp has become a trusted name in the industry. With more than 100 locations across Germany, Interhyp has an extensive network to cater to its customers' needs. Founded in 1999, Interhyp has a team of around 1600 highly skilled employees and collaborates with over 500 financing partners. This allows the company to provide its customers with a wide range of financing options tailored to their specific needs. Interhyp takes pride in its commitment to excellence and customer satisfaction. ## Challenges **Interhyp, as a financial broker, faces many challenges that are common to other institutions in the sector.** - **Providing personalized services:** Today's customers expect financial brokers to provide personalized services that cater to their unique needs. However, delivering such services can be challenging as brokers need to balance providing personalized services with maintaining efficiency and profitability. - **Keeping up with technological advancements:** The financial sector is witnessing rapid technological advancements. The rise of fintech companies has put pressure on traditional financial institutions to adopt new technologies to remain competitive. Financial brokers like Interhyp must stay updated with the latest technologies to meet customer expectations. - **Eliminating cybersecurity threats:** With the increasing use of digital channels, financial institutions face a growing risk of cyber-attacks. Cyber-attacks can lead to data breaches, financial losses, and reputational damage. Hence, financial brokers must implement robust cybersecurity measures to safeguard customers' sensitive information. - **Building trust:** Trust is crucial in the financial sector, and financial brokers must ensure that they maintain a good reputation. Establishing trust with customers is a long-term strategy that cannot be neglected. **Interhyp understands these challenges and has been working towards meeting them over the last many years.** ![Shield with lock icon](/static/shield-with-lock-icon.svg) ![Government building](/static/government-building.svg) ## Interhyp faced some unique challenges ### The constant need for improvement had outgrown their previous container platform Interhyp began its containerization journey back in 2017. However, they faced difficulties when they wanted to work with other latest cloud native or open source solutions due to the severe restrictions and vendor lockin imposed by their previous Container Platform. When their platform version was End of Life (EOL), Interhyp saw this as a perfect opportunity to explore other offerings in the container management space. ### Unnecessary financial burden The potential impact of not having another platform in place before the predecessor ran out, would be a huge financial burden, as end-of-life extended support tends to be 2-3X more expensive than supported versions. Interhyp needed to find an alternative platform that could provide reliable and cost-effective solutions, within 1.5 years. ### Ensure employer attractiveness remained high Due to its complexity and inability to handle other open-source solutions, Interhyp found the adoption of Openshift to be a challenge among its teams. Interhyp wanted to ensure that its teams could work with the latest technologies to attract the best talent in the industry. This required finding a platform that was easy to work with and enabled working with the latest open-source cloud native solutions. Interhyp recognized the importance of overcoming these challenges to stay competitive and provide its customers with the best services. Hence, it sought an alternative platform that could provide the flexibility, scalability, and cost-effectiveness that was essential for its business success.
 By doing so, Interhyp ensured that it could attract and retain the best talent while providing its customers with reliable and innovative solutions. > Kubermatic and KubeOne have helped us kickstart our cloud native journey and to embark on a hybrid cloud approach. While making optimum use of our existing hardware, we were able to boost our engineering teams to deliver new products in less than a day while running their services on a reliable and resilient platform. ## Other Considerations In addition to the challenges mentioned earlier, Interhyp recognized the need for a new platform that would make its business future-ready. To achieve this, Interhyp envisioned the new platform to have the following qualities: - Compatibility with Azure Kubernetes Services (AKS) was essential - Development teams wanted to automate more deployments using GitOps and open-source technologies to streamline the delivery process. This would help them save time and reduce the risk of errors while ensuring consistency and reliability. - The platform should easily spawn clusters or nodes when needed, without requiring significant effort or time from the development teams. This would help scale operations rapidly to meet customer demands. > **The new platform should ideally help Interhyp leverage the latest technologies, streamline its operations, and scale its business rapidly while ensuring consistency, reliability, and security.** ## Solution With **Kubermatic KubeOne**, Interhyp is easily able to manage the full lifecycle of kubernetes clusters on bare-metal environment. This includes provisioning, upgrading and repairing clusters whenever necessary. KubeOne offers a reliable, highly available solution for on-prem environments. With KubeOne, you can run high availability Kubernetes clusters in your own environment without the need to change your current technology stack. If you're running a matured operating system or re-utilizing hardware, we can turn that infrastructure into a state-of-the-art cloud native environment so it works seamlessly with the rest of your stack and doesn't require any changes to how you work or update your systems. KubeOne is a command line interface (CLI) tool, so it's perfect for automation or orchestration scripts. With the best on-premise air gapped offering in the market, KubeOne creates highly available production-ready clusters on any infrastructure without compromising performance. ![Computer with code editor](/static/computer-with-code-editor.jpg) ## Results & Benefits ### Interhyp has been able to realize several benefits within a short span of time, including: ![](/images/icons/clock.svg) ### Faster time to market Microservice deployment that previously took **two days can now be available for production in just one hour**. This has given Interhyp a significant competitive advantage and enabled it to bring new services to market quickly. Since implementing KubeOne, Interhyp has been consistently releasing an average of 16 micro-services per month, demonstrating the successful adoption of this technology and the company's commitment to continuous innovation. ![](/static/icons/consistency-icon.svg) ### Improved deployment process Building upon KubeOne's automation and its open-source ecosystem, Interhyp's all-new scaffolding process made it easier to deploy new services, reducing the risk of errors and streamlining the deployment process. ![](/static/icons/rocket-icon.svg) ### Increased efficiency company-wide Previously, just 3 members of the IT-operations team worked on the previous Container Platform. Despite multiple efforts to encourage the rest of the development team to adopt Kubernetes, it proved to be a challenging task. Today, all 13 members of the DevOps platform excellence team at Interhyp work with KubeOne. Improved knowledge dissemination and higher technology adoption have created the perfect environment for development teams to execute their ideas quickly. This shift has resulted in greater efficiency and productivity, allowing Interhyp to stay competitive in a rapidly evolving market. ![](/images/icons/shaking-hands.svg) ### Zero downtime With high availability features, Interhyp continues to avoid unplanned downtimes, ensuring that its services are always available to customers. This helps Interhyp in maintaining trust and confidence among its customers, which is critical in the financial sector. ![Double quotes image](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==) Building upon cloud native technology, we are able to shift our workload between on-premise and global hyperscalers. Moreover, our new KubeOne platform enables us to meet our strict data protection, compliance and security requirements while reducing maintenance efforts and downtimes. Willi Bühler, Head of Application Technology, Interhyp AG ![Willi Bühler, Interhyp](/static/Willi-Buhler_hu_5d80e96e32dcb2d3.png) --- ## Lines of Defense - Securing your Kubernetes Clusters - **URL:** https://www.kubermatic.com/resources/lines-of-defense-securing-your-kubernetes-clusters/ - **Date:** 2023-04-11 - **Description:** Watch Koray Oksay in his talk at ContainerDay Security 2023 and learn how to run Kubernetes clusters securely and how to counteract security challenges. # Lines of Defense - Securing your Kubernetes Clusters ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Koray Oksay's talk at ContainerDay Security 2023 Kubernetes has become the de facto standard for container orchestration, and it is being widely adopted by organizations of all sizes. However, as with any complex system, there are a number of security challenges that need to be addressed in order to properly secure a Kubernetes deployment. In his talk, Koray will first show you some security problem areas in Kubernetes and then give an overview of various security tools such as image screening and auditing. You will learn how to run Kubernetes clusters securely and how to proactively counteract security challenges. **Speaker: Koray Oksay, Consultant / SRE / Trainer at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Master Your Cloud Native Deployment with KKP 2.22 - **URL:** https://www.kubermatic.com/blog/master-your-cloud-native-deployment-for-maximum-control-with-kkp-2-22/ - **Date:** 2026-05-07 - **Description:** The 2.22 release of Kubermatic Kubernetes Platform introduces web terminal, IP allowlist and KubeVirt GA to control your kubernetes deployment - **Categories:** Products - **Tags:** KKP - **Authors:** Mita Bhattacharya Today, we are excited to announce the release of the **Kubermatic Kubernetes Platform (KKP)**, available in both Enterprise Edition (EE) and Community Edition (CE). The **open-source Community Edition** is driven by a passionate community of users from around the world, with some running thousands of clusters. The **Enterprise Edition** boasts powerful features designed to help large organizations get the most out of their Kubernetes clusters in terms of governance, security, and management. With both editions, you can take control of your Kubernetes clusters and unlock their full potential. With this release, KKP users can expect several usability and security improvements, such as a simplified process for MLA stack installation, customizable cluster templates, and enhanced security measures. Additionally, KKP users will be able to leverage improved access control, which will allow them to more securely manage user access to the cluster. These features will provide users with greater insight and control over their deployments, which will lead to improved efficiency and productivity. KKP 2.22 introduces support for Ubuntu 22.04 LTS, Kubernetes 1.25 & 1.26. The Operating System Manager (OSM) introduced in KKP 2.21 and MachineController also support Kubernetes 1.25 & 1.26. Read on for these and other key updates with this release:  ## Create independent control planes by natively accessing KubeOne clusters in KKP  ### (CE and EE) This release marks another milestone in bringing cloud and edge services to the next level.  KKP 2.22 onwards KubeOne clusters are managed just like any other external provider - that means as a KKP user you can import KubeOne clusters natively. With a wizard, users can now import KubeOne clusters from Amazon Web Services (AWS), Azure Cloud and Google Cloud Platform (GCP).  ![Importing KubeOne Cluster with KKP Wizard](/static/importing-kubeone-cluster-with-kkp-wizard.png "Importing KubeOne Cluster with KKP Wizard") Teams can now configure independent control planes that are part of a larger, centralized management system, allowing them to solve challenges on an individual level while operations teams gain leverage to provide support.  This will enable teams to gain greater control over their deployments, allowing them to optimize efficiency and productivity while ensuring a secure and reliable experience. ## Experience maximized accessibility with Web terminal ### (CE and EE) Web terminal can also be used to remotely access and manage multiple clusters simultaneously, streamlining the process and saving time. Additionally, it also provides enhanced visibility and control, allowing admins to quickly troubleshoot and manage their clusters more efficiently. With web terminal, KKP admins can access and carry out activities from their browser directly. Admins can hook into any cluster using the CLI features from a device that only has a browser-they do not need a terminal on it.  Once the session is complete, the connection is dynamically disabled to prevent any nefarious activity. ## Run Kubernetes clusters on-premise with KubeVirt cloud provider ### (CE and EE) Teams that have been unable to adopt Kubernetes due to the presence of existing Virtual Machine-based workloads that cannot be easily containerized now have a powerful solution - KubeVirt!  **KubeVirt Cloud Provider** - KubeVirt combined with Kubermatic eliminates the need for running dedicated platforms to manage virtual machines on-premise and allows the automatic deployment of Kubernetes clusters on them. With this release, our **KubeVirt Cloud Provider is GA!** Teams can now take advantage of the platform's full capabilities and reap the benefits of a unified development platform. Benefits include: * Single platform to manage all virtual machines * Quickly and easily create kubernetes clusters on-premise ![Running kubernetes cluster on top of KubeVirt VMs](/static/running-vms-and-containers-side-by-side-with-kubevirt-.png "Running kubernetes cluster on top of KubeVirt VMs") ## Improved user experience with every release ### (CE and EE) As always, our goal with KKP is to make the user experience more intuitive and enjoyable. With KKP 2.22, we have made several changes to the user interface that will further improve the overall usability of our platform. These changes include: * The project and admin panel navigation has been enhanced with secondary levels. With this new grouping of menu points under concise headers it will be easier to find what you are looking for. This also allows us to expand the interface more easily in the future, ensuring that every new feature will be exactly where you expect it. This includes a redesigned sidebar to accommodate more intuitive navigation.  ![Navigation bar](/static/navigation-bar.png "Navigation bar") * To gain a better understanding of the seed cluster, users can view the following information  * Credentials are in use * The number of clusters generated  * Cloud provider where the clusters are hosted This gives users a comprehensive overview of their seed cluster and allows them to manage it more productively. * Since KKP 2.21, user clusters have been able to run in dual-stack mode on a variety of cloud providers, including AWS, Azure, Equinix Metal, and GCP. This allows users to assign both an IPv4 and IPv6 address to their resources such as pods and Kubernetes services. With KKP 2.22, we have further expanded the list of supported providers, improved the experience on some operating systems, and integrated new Cloud Configuration Management (CCM) tools as they are added to KKP for particular cloud providers. * Cluster templates have not only been enriched with the edit feature, but also with the new customization functionality. 'Customize template' allows you to quickly make any number of alternate clusters based on your pre-existing settings without altering the template itself. Making new clusters on the fly has never been easier. ## The Smartest way to manage resources and costs with QuotaFlow ### (EE Only) With KKP 2.21, KKP admins began managing consumption anywhere, irrespective of an individual provider. Admins can limit the resources consumed by all cloud providers within every project individually. With KKP 2.22, we have also introduced the possibility of setting default project resource quotas- this is used if no quota is set explicitly.  ![Setting default resource quotas in KKP](/static/setting-default-resource-quotas-in-kkp.png "Setting default resource quotas in KKP") Users can also view dynamic/live quota gauges: this view represents resource quota forecasts based on adding/editing/removing compute resources, during the cluster creation process. ![Resource view during cluster creation](/static/resource-view-during-cluster-creation.png "Resource view during cluster creation") ## A simplified approach to application management ### (CE and EE) Since KKP 2.21, as a KKP Admin, you can browse, pick and install applications throughout the user clusters. With KKP 2.22, we have introduced even more improvements: * Application upgrades: Now you can easily change the version of an Application directly in the UI. * Extends application's CRDs with DeployOptions.HelmDeployOptions to control how applications are deployed with Helm. (allow to specify equivalent of -- wait, --timeout, --atomic flags). When DeployOptions are defined at ApplicationDefinition level, it acts as a default for all ApplicationInstallation. However, it can be overridden at ApplicationInstallation level. * Application reconciliation: Allow to periodically force the reconciliation even if Application Installation CR has not changed. * The installation or upgrade of an application is automatically stopped if the maximum number (5) of tries is exceeded  ## Enhanced enterprise security with every release ### (CE and EE) With KKP 2.22, accessing clusters securely via OIDC authentication for kubeconfig elevates access control and lets admins run safer environments * Instead of a service account, the OIDC account will authenticate within kubeconfig. This way the KKP admin can set up user-level access control, allowing them to specify exactly which team members can access which clusters * With the IP allowlist, KKP admins can restrict access to the kubernetes clusters to only those IP addresses specified in the allowlist. This helps ensure that only authorized members of the organization can access cluster credentials and helps prevent malicious actors from accessing the cluster. ## What’s next for KKP? To better serve the open source endeavor, we strive to create an ecosystem that allows members to suggest their requirements. As a step in this direction, we are happy to announce that in the near future, we will include support for Vultr, as per the request by [@2000yeshu and in line with community-led requests.](https://github.com/kubermatic/machine-controller/pull/1531) Stay tuned for more! At Kubermatic, we take customer feedback and expectations very seriously. That's why we have a specialized team that's responsible for analyzing all of the feedback that we receive. This team plays a crucial role in ensuring that our product is always aligned with the needs of our customers. Our primary objective is to make sure that our product is result-oriented. This means that we are constantly working to improve the effectiveness and efficiency of our product so that it delivers the best possible results for our customers.  In addition to being result-oriented, we also place a strong emphasis on security.Our team works tirelessly to identify and address any potential security risks, and we implement the best practices and technologies to keep our platform as secure as possible. Finally, we are committed to providing excellent product support. Our customers can always count on us to be there when they need us, and we work hard to ensure that they have a positive experience when they interact with us. Whether it's answering a question, fixing a bug, or providing guidance on how to use our platform, we are here to help. We hope you enjoy the new capabilities that our release offers. Get exploring yourself and tell us about your KKP experience. You can reach out to us via [Github](https://github.com/kubermatic/), {{< slackjoinlink "Slack" >}}, or [lots of other ways](https://www.kubermatic.com/company/community/#discussions). ## Learn More * Check out the entire [changelog](https://github.com/kubermatic/kubermatic/blob/main/docs/changelogs/CHANGELOG-2.22.md#v2220) * Read our [solution brief](/static/KKP_2.22_Solution_Brief.pdf?v=2) --- ## KubeOne 1.6 Out Now: Easy Kubernetes Start - **URL:** https://www.kubermatic.com/blog/kubeone-1-6-out-now-the-easiest-way-to-get-started-with-kubernetes/ - **Date:** 2026-05-07 - **Description:** Want to get started with Kubernetes but don't know where to start? Check out KubeOne 1.6! - **Categories:** Company, Community - **Tags:** Announcements, Open Source Projects - **Authors:** Mita Bhattacharya ## PRESS RELEASE We are excited to announce the release of KubeOne 1.6. KubeOne is completely open source and provides organizations with full lifecycle management of clusters, including provisioning, upgrading, and repairing them whenever necessary. It’s a command line interface (CLI) tool, so it’s perfect for automation or orchestration scripts. “With KubeOne 1.6, we wanted to make it easier than ever for users to get started with Kubernetes. As such, improving the user experience was a top priority for the development team. With the latest version, KubeOne has become even more streamlined, intuitive, and user-friendly than before, making it easier than ever for our users,” said **Sebastian Scheele, CEO at Kubermatic.**  The highlights of KubeOne 1.6 are as follows: ## Enhanced User Experience With Helm Based Addons Long ago, we introduced "Addons" as a way to deploy Kubernetes resources during cluster reconciliation. Addons proved to be convenient and were used to deploy various components such as CNIs, CCM/CSI, and more. However, addons only support plain YAML files. This can be problematic as many components are now shipped as Helm charts, affecting the user experience. KubeOne 1.6 introduces Helm-based addons to improve the user experience. Users just provide a list of Helm charts to deploy in the KubeOneCluster manifest, for example ```yaml apiVersion: kubeone.k8c.io/v1beta2 kind: KubeOneCluster versions: kubernetes: 1.26.1 cloudProvider: aws: {} helmReleases: - releaseName: ksm chart: kube-state-metrics repoURL: https://prometheus-community.github.io/helm-charts namespace: kube-state-metrics version: 4.25.0 ``` KubeOne 1.6 integrates Helm for the full lifecycle of Helm charts, including installation, updates, and uninstallation if needed. More information about this feature can be found in the official documentation [here](https://docs.kubermatic.com/kubeone/v1.6/guides/helm-integration/).  ## Get Started With KubeOne With Just 3 Commands Our goal is to simplify the KubeOne setup process by only requiring the KubeOne binary. Previously, users had to obtain Terraform files from GitHub or a release archive, manually create a KubeOneCluster manifest and set Terraform variables if using our configurations. Users can now get started with the newly-added \`kubeone init\` subcommand! This new subcommand will ask the user for a bunch of parameters, and based on the provided parameters it’s going to generate KubeOneCluster manifest and Terraform configurations and variables. This command can be used in two ways:  * by providing parameters using flags or  * by using the interactive mode. The interactive mode will guide the user through the process step-by-step and give recommendations on which features might be valuable based on the setup. ![Set up KubeOne with kubeone init subcommand](/static/kubeone-init-command.jpg "Set up KubeOne with kubeone init subcommand") With KubeOne's new setup process, you'll only need to run three commands to get started with Kubernetes: terraform init, terraform apply, and kubeone apply.  ## Experimental Support For Dual-Stack Clusters KubeOne 1.6 comes with experimental support for IPv4/IPv6 Dual-Stack clusters on AWS and bare metal clusters. Dual-Stack support gives users an option to use both IPv4 and IPv6 addresses for pod networking. This includes creating Services and exposing workloads via both IPv4 and IPv6 addresses. This feature is currently available only for newly-created clusters by setting the following option in the KubeOneCluster manifest: ```yaml apiVersion: kubeone.k8c.io/v1beta2 kind: KubeOneCluster versions: kubernetes: 1.26.1 cloudProvider: aws: {} clusterNetwork: ipFamily: "IPv4+IPv6" ``` For more details about available options, please consider our API reference [here](https://docs.kubermatic.com/kubeone/v1.6/references/kubeone-cluster-v1beta2/#clusternetworkconfig). ## Support for the Latest Kubernetes Releases KubeOne 1.6 introduces support for two new Kubernetes minor releases: 1.25 and 1.26.  This allows users to access all the latest features in the upstream development, as well as, to easily stay on a supported Kubernetes version.  Additionally, KubeOne can manage up to Kubernetes 1.24. Please check the upgrade guidelines [here](https://docs.kubermatic.com/kubeone/v1.6/tutorials/upgrading/upgrading-from-1.5-to-1.6/) and the Kubernetes [compatibility matrix](https://docs.kubermatic.com/kubeone/v1.6/architecture/compatibility/supported-versions/) for more information. These are just a few of the amazing features included in this release. Be sure to review the full changelog for a complete list of enhancements, updates, and bug fixes that will enhance your experience. Follow us on GitHub for updates on future developments - we have exciting plans for KubeOne 1.7, including further enhancements to dual-stack support, improvements to Helm addons, and more! KubeOne 1.6 is available for use as of 28 February 2023. ### Additional Resources * KubeOne [Documentation](https://docs.kubermatic.com/kubeone/v1.6/) * KubeOne 1.6 Release [Changelog](https://github.com/kubermatic/kubeone/blob/main/CHANGELOG/CHANGELOG-1.6.md) --- ## Maximize Control Over Cloud-Native Deployment With KKP 2.22 - **URL:** https://www.kubermatic.com/blog/maximize-control-over-cloud-native-deployment-with-kkp-2-22/ - **Date:** 2026-05-07 - **Description:** Press release for Kubermatic Kubernetes Platform (KKP) 2.22 - **Categories:** Company, Community - **Tags:** Announcements, Open Source Projects ## **Press Release** We are excited to announce the release of **Kubermatic Kubernetes Platform (KKP)** **version** **2.22** in both Enterprise Edition (EE) and Community Edition (CE). CE is completely open source, while EE boasts powerful features designed to help large organizations get the most out of their Kubernetes clusters in terms of governance, security, and management.  This release is packed with exciting usability and security enhancements. “The ultimate aim of these enhancements is to empower KKP users with enhanced visibility and authority over their deployments. With improved control, outstanding outcomes are guaranteed,” said **Sebastian Scheele, CEO at Kubermatic.**  Important benefits introduced in KKP 2.22 include: * **Creating independent control planes by natively accessing KubeOne clusters in KKP**: KubeOne clusters are now managed just like any other external provider- that means KKP users can import KubeOne clusters natively.  * **Maximizing accessibility with Web terminal**: Admins can hook into any cluster using the CLI features from a device that only has a browser-they do not need a terminal on it. This is a very secure connection that’s dynamically disabled once the session is complete to eliminate any nefarious activities. * **Run kubernetes clusters on-premise with KubeVirt Cloud Provider** : With this release, KubeVirt Cloud Provider is GA on KKP! KubeVirt Cloud Provider is KubeVirt combined with Kubermatic. It eliminates the need for running dedicated platforms to manage virtual machines on-premise and allows the automatic deployment of Kubernetes clusters on them. * **Managing resources and costs with QuotaFlow**: Possibility to set default project resource quotas- this is used if no quota is set explicitly. Users can also view dynamic/live quota gauges: this view presents resource quota forecasts based on adding/editing/removing compute resources.  With this release, KKP users can expect several usability and security improvements, such as a simplified process for MLA stack installation, customizable cluster templates, and enhanced security measures.  This release also introduces support for Ubuntu 22.04 LTS, Kubernetes 1.25 & 1.26. The Operating System Manager (OSM) introduced in KKP 2.21 and MachineController also support Kubernetes 1.25 & 1.26. For more information, make sure you read our release [blog](https://www.kubermatic.com/blog/master-your-cloud-native-deployment-for-maximum-control-with-kkp-2-22/). Both CE and EE versions are available for download as of 28 February 2023. [KubeOne 1.6](https://www.kubermatic.com/blog/kubeone-1-6-out-now-the-easiest-way-to-get-started-with-kubernetes/) is also available for download as of 28 February 2023. KubeOne is completely open source. Additional Resources * KKP 2.22 Release [Changelog](https://github.com/kubermatic/kubermatic/blob/main/docs/changelogs/CHANGELOG-2.22.md#v2220) * KKP 2.22 [Solution Brief](/static/KKP_2.22_Solution_Brief.pdf?v=2) --- ## eBook - Minimize to Maximize in 5 Steps - **URL:** https://www.kubermatic.com/minimize-to-maximize/minimize-to-maximize-in-5-steps/ - **Date:** 2023-08-28 - **Description:** Data centers are among the world’s biggest consumers of energy. Download the eBook to learn how your organization can minimize energy consumption in the data center to maximize cost savings and productivity. ![Kubermatic branding element](/static/containerdays-bg.svg) # Minimize to Maximize in 5 Steps ## eBook ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Data centers are among the world’s biggest consumers of energy. Computational hardware and cooling consume 86% of a data center’s energy. In view of the cost of the energy crisis the world is facing right now, minimizing energy consumption in the data center is more important than ever. This is your chance to learn **how to minimize consumption and maximize performance**. Discover the 5 steps to achieving your goal in this eBook. If our form couldn't load correctly – This can have multiple reasons like ad blocker, not accepted cookies, JavaScript deactivated. However, you can still get in touch with us! Simply click on the button below, and you'll be able to submit the form and reach out to us for any inquiries or assistance you need. [Open form](https://share.hsforms.com/1hKVZuL8OTdyMSu3oAwinaw2piu8) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) --- ## Whitepaper - Energy is Key - **URL:** https://www.kubermatic.com/minimize-to-maximize/energy-is-key/ - **Date:** 2023-08-28 - **Description:** In light of recent developments in the global markets, energy consumption is the latest topic in every board room. This whitepaper evaluates some of the mechanics to reduce consumption of energy within cloud and edge computing. ![Kubermatic branding element](/static/containerdays-bg.svg) # Minimize to Maximize ## A Research Whitepaper ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Energy is Key According to recent reports, the energy forecast for 2030 portrays that 21% of global energy will be consumed by IT. In light of recent developments in the global markets, energy consumption is the latest topic in every board room and something has to happen now. This whitepaper evaluates some of the mechanics to reduce consumption of energy within cloud and edge computing. This is your chance to learn **how to minimize consumption and maximize cost savings and productivity.** If our form couldn't load correctly – This can have multiple reasons like ad blocker, not accepted cookies, JavaScript deactivated. However, you can still get in touch with us! Simply click on the button below, and you'll be able to submit the form and reach out to us for any inquiries or assistance you need. [Open form](https://share.hsforms.com/1HR8C2e2ESQGgj1Y6y_fcZA2piu8) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) --- ## Minimize to Maximize - **URL:** https://www.kubermatic.com/minimize-to-maximize/ - **Date:** 2026-03-30 - **Description:** Rising energy prices demand more focus on sustainable high performance solutions at low cost. Kubermatic enables you to monitor, automate and optimize resources in the data center. # Minimize to Maximize Minimize Data Center Energy Consumption to Maximize Cost Savings and Productivity Minimize Data Center Wastage to Maximize Performance Minimize Data Center Carbon Footprint to Maximize Sustainable Growth ![Electric pole icon](/static/electric-pole-icon.svg) Today, data centers account for up to 1.5% of **global energy consumption** ![Photo from space](/static/photo-from-space_hu_5dbbe11e58461dc0.jpg) ![Earth icon](/static/earth-logo.svg) By 2030, forecasted global IT consumption will be at **21%** ![Power plant](/static/power-plant_hu_48a3fd777f75f080.jpg) ![Bulb icon](/static/bulb-logo.svg) **Automating** containerised workflows optimizes compute resources ![Robot](/static/robot_hu_20f467f1676188b5.jpg) ![Rectangle with exclamation icon](/static/rectangle-with-exclamation.svg) ## Energy consumption has become a boardroom issue. Rising energy prices demand more focus on sustainability and green IT, particularly in the data center. Half of the energy consumed in a data center is wasted by compute hardware that spends 88% of its time idling. This risks increasing exponentially as organizations embrace the power of cloud native technologies. This level of wastage can't continue when the cost of the fuel crisis to businesses and communities is so high. Neither can we afford the risk of downtime due to potential blackouts or power outages. ![Rectangle with checkmark icon](/static/rectangle-with-checkmark.svg) Through the power of automation, Kubermatic enables the optimization of data centers. It means you'll only run servers when they're needed and turn them off when they're idle. Make smarter decisions, such as performing your daily payment processing at night when energy is cheaper, or using resources when they're available, like solar power in the daytime. This can save up to 33% on your data center's energy consumption and associated costs. ## Kubermatic enables you to minimize waste and energy consumption in your data center to maximize cost savings and performance. ## Kubermatic enables you to: ![Add database icon](/static/add-db-icon.svg) ### Only run workloads when they're needed ![Cloud centric icon](/static/cloud-centric-icon.svg) ### Automatically scale down when resources are idling ![Money care icon](/static/money-care-icon.svg) ### Maximize cost savings and achieve zero downtime ## Learn More Whitepaper [![Colourful ferris wheel](/static/energy-is-key_hu_74c231e23864b692.jpg)](/minimize-to-maximize/energy-is-key/) ## [Energy is Key](/minimize-to-maximize/energy-is-key/) [Download](/minimize-to-maximize/energy-is-key/) Infographic [![Spinning containers - Consume less, Reduce costs, achieve more.](/static/minimize-to-maximize-info_hu_3bbfd67cc22756d9.jpg)](/static/Minimize-data-center-wastage-to-maximize-performance.pdf) ## [Minimize to Maximize](/static/Minimize-data-center-wastage-to-maximize-performance.pdf) [View](/static/Minimize-data-center-wastage-to-maximize-performance.pdf) eBook [![The light bulb is on](/static/minimize-to-maximize-in-5-steps_hu_6c7d368e6a452d80.jpg)](/minimize-to-maximize/minimize-to-maximize-in-5-steps/) ## [Minimize to Maximize in 5 Steps](/minimize-to-maximize/minimize-to-maximize-in-5-steps/) [Download](/minimize-to-maximize/minimize-to-maximize-in-5-steps/) Want to know more? [Visit our website](/) --- ## IPv6 / Dual-Stack in Kubernetes - Why, When, Where and How? - **URL:** https://www.kubermatic.com/resources/ipv6-dual-stack-in-kubernetes-why-when-where-and-how/ - **Date:** 2022-12-01 - **Description:** In this talk, I will explain why we should care about IPv6 in Kubernetes clusters, and when it makes sense to use dual-stack. I will also give an overview on different levels of IPv6 support across several cloud providers, to help with choosing the one which matches your dual-stack use-case best. # IPv6 / Dual-Stack in Kubernetes - Why, When, Where and How? ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Rastislav’s talk at ContainerDays 2022 In Kubernetes 1.23, the dual-stack networking feature that allows simultaneous usage of both IPv4 and IPv6 addresses in Kubernetes clusters was promoted to stable. In this talk, I will explain why we should care about IPv6 in Kubernetes clusters, and when it makes sense to use dual-stack. I will also give an overview on different levels of IPv6 support across several cloud providers, to help with choosing the one which matches your dual-stack use-case best. Last but not least, I will also describe how dual-stack works in Kubernetes clusters and showcase that in a live demo. **Speaker: Rastislav Szabo, Software Engineer at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Reverse K8s resources: from YAML to Go structs - **URL:** https://www.kubermatic.com/resources/reverse-k8s-resources-from-yaml-to-go-structs/ - **Date:** 2022-12-01 - **Description:** In the Kubernetes world, it is a common use case to convert API resources written in Go to YAML manifests for further distribution whether as part of helm chart, kustomize template or other tools. # Reverse K8s resources: from YAML to Go structs ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Jan’s talk at ContainerDays 2022 In the Kubernetes world, it is a common use case to convert API resources written in Go to YAML manifests for further distribution whether as part of helm chart, kustomize template or other tools. How hard can it be to go the other way around, take a YAML manifest and generate a valid Go code from that? This session looks at Kubernetes codecs, scheme, Go reflections, and Go AST parsers from a little unusual perspective. **Speaker: Jan Wozniak, Software Engineer at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Containers and Kubernetes are here - ok, but what’s next? - **URL:** https://www.kubermatic.com/resources/containers-and-kubernetes-are-here-ok-but-whats-next/ - **Date:** 2022-12-01 - **Description:** Many IT organizations are facing the challenge that there is no fast and self-service based way to consume the service of other expert teams. # Containers and Kubernetes are here - ok, but what’s next? ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Sebastian’s keynote at ContainerDays 2022 Many IT organizations are facing the challenge that there is no fast and self-service based way to consume the service of other expert teams. What we need is the option that all teams are able to provide their service via an API. **Speaker: Sebastian Scheele, CEO & Co-Founder at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Running Kubernetes in a Manufacturing Line - **URL:** https://www.kubermatic.com/resources/running-kubernetes-in-a-manufacturing-line/ - **Date:** 2022-12-01 - **Description:** Imagine your manufacturing line is controlled by services running in your datacenters’ Kubernetes clusters. You have facilities in locations all over the world. # Running Kubernetes in a Manufacturing Line ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Mario’s and Tobi’s talk at ContainerDays 2022 Imagine your manufacturing line is controlled by services running in your datacenters’ Kubernetes clusters. You have facilities in locations all over the world. You provide a managed service with uptime SLA. Now, there is an issue with the internet connection. **Speakers: Mario Fahlandt, Teamlead / Kubernetes Consultant & Tobias Schneck, Principal Software Architect at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## GitOps in Practice - **URL:** https://www.kubermatic.com/resources/gitops-in-practice/ - **Date:** 2022-12-01 - **Description:** In my session, I would like to showcase live demo with multiple environments and how ArgoCD can help use GitOps effectively in Helm repository scenario and Git repository scenario. # GitOps in Practice ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Vijay’s talk at ContainerDays 2022 While there are many tutorials on web about how to setup GitOps tool like ArgoCD, most of them do not provide knowledge how it can be used in practical scenario: 1. Using same Git Repo for multiple environments like DEV, TEST, PROD, etc. 2. Promotion of change from one environment to another environment. In my session, I would like to showcase live demo with multiple environments and how ArgoCD can help use GitOps effectively in Helm repository scenario and Git repository scenario **Speaker: Vijay Dharap, Kubernetes Consultant at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## The future of CRDs in a post-cluster world - **URL:** https://www.kubermatic.com/resources/the-future-of-crds-in-a-post-cluster-world/ - **Date:** 2022-12-01 - **Description:** CRDs and operators work well in a single cluster. In a multi- or post-cluster world they don’t. Managing CRDs and operators themselves becomes awkward and a problem in itself. # The future of CRDs in a post-cluster world ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Sebastian's and Stefan's talk at ContainerDays 2022 CRDs and operators work well in a single cluster. In a multi- or post-cluster world they don’t. Managing CRDs and operators themselves becomes awkward and a problem in itself. With many many clusters, we need new solutions. What if an operator and CRDs had first-class support to provide services in many clusters, natively implemented in the apiserver? This talk is about lifting both up, and with that demonstrating how a world looks like where CRD-based APIs and applications are available in a fleet of clusters, independent of cloud, data center and region, for one enterprise or highly multi-tenant service providers. **Speakers: Sebastian Scheele, CEO & Co-Founder at Kubermatic & Stefan Schimanski, Tech Lead API Server at Red Hat** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Changing Paradigms: Cloud | Edge & Hybrid with KKP 2.21! - **URL:** https://www.kubermatic.com/blog/release-kkp-2-21/ - **Date:** 2026-05-07 - **Description:** The 2.21 release of Kubermatic Kubernetes Platform introduces production ready Operating System Manager (OSM) & completely air-gapped user clusters - **Categories:** Products - **Tags:** KKP - **Authors:** Mita Bhattacharya Today, we announce the latest release of **Kubermatic Kubernetes Platform (KKP)**- both **Enterprise Edition (EE) and Community Edition (CE)**. The community driven  CE is completely open source with users around the world, some of them running thousands of clusters. The EE has exclusive features for large organizations to perform better in governance, security and management.  With this exciting new release, the KKP **Operating System Manager (OSM)** **is now ready for production environments** to improve enterprise air-gapping.  There's no need to worry about exceeding your allocated project costs anymore - with KKP 2.21, you can set resource quota limits for all cloud providers within individual projects.  Now KKP admins can create an app catalog and  users can browse through it to deploy third party applications in user clusters within minutes.  The new upgrades to KubeVirt wizard make managing virtualized and container workloads so much easier! It is now possible for KKP users to not only manage but also **create AKS, EKS and GKE clusters directly from the KKP dashboard!**  Due to Docker Hub's rate limiting, KKP admins without subscriptions to the paid tier had difficulty installing KKP. With this release, KKP admins can pull machine-controller images from Quay instead of Docker Hub. Additionally, **KKP 2.21 supports VMware Cloud Director and Rocky Linux**.  Read on for these and other key updates with this release: # **Manage your OS like a pro-get more control over your hybrid and edge deployments**  **(CE and EE)** It’s not yet very common to speak about edge computing and kubernetes together in the same sentence, but both are gaining rapid popularity as more people rely on applications that require proximity to the network. Edge solutions help reduce latency because they act immediately instead of waiting around until data has traveled halfway across town before processing requests.  Better control over your OS, in both hybrid and edge environments, is the key to success. That’s where the **Operating System Manager (OSM)** comes in. With its success as an experimental project, OSM is now ready for production environments!  OSM  extends the functionality of the [Kubermatic Machine-Controller](https://github.com/kubermatic/machine-controller). It is responsible for creating and managing the required configurations for worker nodes in a Kubernetes cluster. It decouples the operating system configurations into dedicated and isolated resources.  An Operating System Profile (OSP) allows to configure: * Real Time OS * Lightweight OS * OS per Provider (Container OS on GCP, Amazon Linux 2 on AWS) We are working on an OSM Agent that helps with inplace upgrades of nodes and other edge cases to support the workloads of tomorrow. # Security without compromise for your enterprise **(EE only)** With KKP 2.21 users can run completely air gapped user clusters. The result is that you can keep sensitive company areas completely off the internet while using the latest container technologies! New clusters can be provisioned without an internet connection. # Don't track costs, manage them **(EE only)** With KKP 2.21, KKP admins can manage consumption anywhere, irrespective of an individual provider. Admins can limit the resources consumed for all cloud providers within every project individually. This enables better distribution of available resources between KKP users.  As a KKP Admin, you can * Define a maximum allocated CPU, memory and disk size allowed to be used by a specific project * Dynamically monitor the amount of resources being used in specific projects in the Admin panel ![Resource management with KKP](/static/resource-management-with-kkp.png) ![Project Overview with KKP](/static/project-overview-with-kkp.png) # Quickly deploy third-party applications  **(CE and EE)** With only a few clicks, you can deploy any third-party application onto user clusters! As a KKP Admin, you can browse, pick and install applications throughout the user clusters. Once installed, applications can be reconciled so that reliability is guaranteed! ![Application catalog during cluster deployment](/static/application-catalog-during-cluster-deployment.png) But this is just the beginning, our implementation is programmed for the future. Use kubernetes-operators or deploy directly from code in future releases - and plug any smart idea into it that you can imagine. For example, GitOps processes can define [App Installations](https://docs.kubermatic.com/kubermatic/main/tutorials-howtos/applications/add-applications-to-cluster/#managing-applications-via-gitops) or [App Definitions](https://docs.kubermatic.com/kubermatic/main/tutorials-howtos/applications/create-application-catalog/#creating-an-applicationdefinition) with ease, the Application Operator we created, takes care of installing some or all apps in the catalogue. Furthermore, these application installations or definitions can be stored in our [Cluster Templates](https://docs.kubermatic.com/kubermatic/v2.20/architecture/concept/kkp-concepts/cluster_templates/). That means, with just two clicks, you can spin up highly complex clusters that include multi-level applications. Integration with our Monitoring, Logging and Alerting Stack is the cherry on top! # Dual stack support is here  **(CE and EE)** The latest standard for networking, IPv6 is quickly becoming the norm. IPv6, provides a virtually limitless number of addresses. User clusters in KKP 2.21 can run in dual-stack mode in AWS, Azure, Equinix Metal, GCP and [other providers](https://docs.kubermatic.com/kubermatic/main/tutorials-howtos/networking/dual-stack/#feature-overview). This means that their resources like pods or Kubernetes services can have both an IPv4 and IPv6 address. This comes in handy in scenarios where customers need to support both legacy workloads that aren’t compatible with IPv6 as well as modern applications that are. ![Dual Stack Configuration during cluster creation process](/static/dual-stack-configuration-during-cluster-creation-process.jpeg) # Datacenter automation with KubeVirt Cloud Provider **(CE and EE)** Using the KubeVirt wizard is now easier than ever before! As a KKP 2.21 user you: * can use predefined or custom virtual machine templates * isolate your VM workload on the bare-metal environment # Eliminate the need to switch between multiple dashboards  **(CE and EE)** From creating your clusters to managing and monitoring them, there is no need for you to have multiple dashboards. With KKP 2.19 you could monitor and operate your external clusters right from the KKP dashboard. Now go one step ahead and create clusters on Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS) or Google Kubernetes Engine (GKE) in the KKP dashboard. Watch as KKP handles all the details, giving you complete peace of mind! ![Selection of External Provider AKS, EKS and GKE](/static/selection-of-external-provider-aks-eks-and-gke.png) ![Creating GKE cluster inside KKP](/static/creating-gke-cluster-inside-kkp.png) # Simplified kubernetes dashboard authentication **(CE and EE)** Logging in to the dashboard of user clusters is now possible via the same OIDC provider that is used for KKP authentication.  # Reflect enterprise access rules in KKP  **(EE only)** Since many enterprises use LDAP groups to manage access across projects and softwares, we wanted KKP to do the same. KKP 2.21 onwards, OIDC groups can be assigned to projects as owners, viewers and editors. Users in the particular group will inherit the permissions from the group on the specific project.  There will be a patch release to ensure compatibility with [Kubernetes v1.25](https://kubernetes.io/blog/2022/08/23/kubernetes-v1-25-release/) soon- keep watching this space for more! ## What’s next for KKP? We have a dedicated team that analyzes product feedback and expectations. Our goal is three-fold: ensuring our product is result-oriented, building an extremely secure platform that will keep your sensitive information safe (and give you peace-of mind) and providing an unparalleled user experience.  We plan to bring the clusters even closer to our users, making interaction and deployment easier than ever before, while continuing to extend our already broad scale of available providers.  Don’t forget that KKP is open source, therefore your ideas and contributions matter! In fact, direct user and customer feedback statistically take 38,6 days to become part of our codebase.  We hope you enjoy the new capabilities that our release offers. Get exploring yourself and tell us about your KKP experience. You can reach out to us via [Github](https://github.com/kubermatic/), {{< slackjoinlink "Slack" >}}, or [lots of other ways](https://www.kubermatic.com/company/community/#discussions). ## Learn More * Read the [KKP 2.21 solution brief](/static/KKP_2.21_Solution_Brief.pdf) * Check out the [entire changelog](https://github.com/kubermatic/kubermatic/blob/master/docs/changelogs/CHANGELOG-2.21.md) --- ## Meet KubeOne 1.5 - Now More Adaptable than Ever! - **URL:** https://www.kubermatic.com/blog/release-kubeone-1-5/ - **Date:** 2026-05-07 - **Description:** The KubeOne 1.5 release comes with support for Kubernetes 1.24 and Operating System Manager that is ready to be used in production environments - **Categories:** Products - **Tags:** KubeOne - **Authors:** Mita Bhattacharya Today, we are pleased to announce that KubeOne 1.5 is now generally available. KubeOne is our open source cluster lifecycle management tool that automates cluster deployment and management in your preferred on-prem, edge, or cloud environment.  With this release, we introduce the kubeone local subcommand to provision a single-node Kubernetes cluster on current machine as well as support for Rocky Linux. We have added VMware Cloud Director to our list of supported providers. Additionally, KubeOne 1.5 supports Kubernetes 1.24. Read on to know more! # Manage Hybrid and Edge Deployments with Operating System Manager (OSM) With its success as an experimental project since it’s introduction in KubeOne 1.4, OSM is now ready for production environments! The OSM decouples operating system configurations into dedicated and isolable resources for better modularity and maintainability. These isolated and extensible resources allow a high degree of customization. This is useful for hybrid, edge, and air-gapped environments. It is enabled by default and is responsible for generating and managing user-data used for provisioning worker nodes.  With regards to this, please note that  * Existing worker machines will not be migrated to use OSM automatically. The user needs to manually rollout all MachineDeployments to start using OSM. Please refer [this](https://docs.kubermatic.com/kubeone/v1.4/cheat_sheets/rollout_machinedeployment/) document for detailed instructions * As an user, you have the choice to opt-out from OSM by setting .operatingSystemManager.deploy to false in their KubeOneCluster manifest  For more details, please refer our documentation [here](https://docs.kubermatic.com/kubeone/main/architecture/operating-system-manager/). # Provision a Single-node All-in-One Cluster on a Local Machine The kubeone local subcommand  helps initializing a cluster on a local machine- let’s call it the local cluster. Container runtime, control-plane and kubelet with some basics like CNI are installed, together with removed taints to unblock the single Node for a regular workloads. We call this “all-in-one cluster”. The feature allows KubeOne to be used in environments that do not support SSH access, such as CI/CD environments, containers, and virtual machines. # Run Kubernetes 1.24 We are always doing our best to ensure support for the newest Kubernetes releases. The [Kubernetes 1.24](https://kubernetes.io/blog/2022/05/03/kubernetes-1-24-release-announcement/) is supported with this release, so you can enjoy all of the newest features and improvements. We are also [conformance certified](https://github.com/cncf/k8s-conformance/pull/2121) for Kubernetes 1.24. The [Compatibility document](https://docs.kubermatic.com/kubeone/main/architecture/compatibility/) includes a list of supported Kubernetes versions for each KubeOne release. We hope the new release of KubeOne helps you operate your Kubernetes clusters with great ease and flexibility. Of course, we are always happy to learn about your thoughts and feedback on our cloud native projects. Just ping us on our {{< slackjoinlink "Community Slack" >}} or on [Github](https://github.com/kubermatic/kubeone).  ## Learn more Read the complete changelog [here](https://github.com/kubermatic/kubeone/blob/master/CHANGELOG/CHANGELOG-1.5.md).  Instructions for upgrading are available [here](https://docs.kubermatic.com/kubeone/v1.5/tutorials/upgrading/upgrading-from-1.4-to-1.5/). --- ## Securing Your Kubernetes Clusters Part 2: How to Proactively Prevent Attacks - **URL:** https://www.kubermatic.com/resources/how-to-keep-your-kubernetes-cluster-safe-from-attacks-part-2/ - **Date:** 2024-10-16 - **Description:** Check out part 2 of our Kubernetes security webinar to learn how to avoid attacks and keep your cluster safe. # Lines of Defense: How to Keep Your Kubernetes Cluster Safe From Attacks - Part 2 ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Watch the webinar and dive into the Kubernetes security best practices! As we migrate more and more workloads into our Kubernetes clusters we ask ourselves: How can we make our clusters safe from vicious attacks? In this two-part webinar series, Hubert will introduce you to Kubernetes security best practices and present tools which make it harder for attackers to do bad things on your clusters. In this second part, you’ll learn about: - How to Proactively Prevent Attacks - How to ensure that you are in control of what is running in your clusters - And more! ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Securing Your Kubernetes Clusters Part 1: How to Avoid Attacks - **URL:** https://www.kubermatic.com/resources/securing-your-kubernetes-cluster-part-1-how-to-avoid-attacks/ - **Date:** 2024-10-16 - **Description:** Check out part 1 of our Kubernetes security webinar to learn how to avoid attacks and keep your cluster safe. # Lines of Defense: How to Keep Your Kubernetes Cluster Safe From Attacks - Part 1 ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Watch the webinar and dive into the Kubernetes security best practices! As we migrate more and more workloads into our Kubernetes clusters we ask ourselves: How can we make our clusters safe from vicious attacks? In this two-part webinar series, Hubert will introduce you to Kubernetes security best practices and present tools which make it harder for attackers to do bad things on your clusters. In the first part, you’ll learn about: - Kubernetes components and smart ways of Kubernetes installations - Securing your worker nodes - And more ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Cilium CNI Integration in Kubermatic Kubernetes Platform - **URL:** https://www.kubermatic.com/blog/cilium-cni-integration-in-kubermatic-kubernetes-platform/ - **Date:** 2026-05-07 - **Description:** Read this blog post to learn how to deploy a Kubermatic cluster with Cilium CNI. - **Categories:** Products - **Tags:** KKP - **Authors:** Rastislav Szabo With Kubermatic Kubernetes Platform 2.19, we introduced support for the Cilium CNI for both, the enterprise and the community edition of our platform. Why? Because we think the Cilium folks are currently building the best open source networking platform for Kubernetes. [Cilium](https://cilium.io/) provides, secures and observes network connectivity between container workloads - cloud native, and fueled by the revolutionary Kernel technology eBPF. [When testing the performance of Canal vs. Cilium](https://www.kubermatic.com/blog/get-the-best-of-both-worlds-with-the-kkp-2-19-cni-strategy/), Cilium performed up to 30% better than Canal when running in ordinary Kubernetes clusters on the same hardware. Sure thing we wanted to make this easily available to our users.  In this blog post, I’ll show you how Cilium and KKP users can benefit from this integration before deep diving into how to deploy a KKP cluster with Cilium CNI and exploring the traffic. ## **Benefits of Cilium CNI for KKP Users** Cilium is a CNCF incubating project that provides, secures and observes network connectivity between container workloads in a truly cloud native way. At the foundation of Cilium is a new Linux kernel technology called eBPF, which enables the dynamic insertion of powerful security, visibility, and networking control logic into the Linux kernel. The main benefits of the Cilium CNI for KKP users include: #### **Transparent Observability** As part of the Cilium integration in KKP, users can easily enable the Hubble add-on in their clusters. Hubble is an observability platform built on top of Cilium and eBPF to enable deep visibility into the communication and behavior of services in a completely transparent manner. By relying on eBPF, all visibility is programmable and allows for a dynamic approach that minimizes overhead while providing deep and detailed insight as required by users. Hubble comes with a  a web user interface as that can be used to investigate networking issues in a much faster and convenient manner than for example by performing tcpdump traces manually at various places in the cluster: ![Hubble UI ](/static/cilium-cni-integration-in-kubermatic-kubernetes-platform-hubble-ui.png) Even if the Hubble UI is not installed in the cluster, the Hubble backend is enabled in the kubermatic clusters by default. The data that it collects can be used to trace traffic via the powerful Hubble CLI. For example, to observe all recent communication of a pod, you just need to type `hubble observe --pod <pod-name>`. #### **Service Load-Balancing Without Kube-Proxy** Service load-balancing in Kubernetes clusters is based on destination network address translation (NAT) of virtual service IP addresses to actual endpoint pod IP addresses. In traditional Kubernetes clusters this is being performed by the kube-proxy component of Kubernetes, which runs on each worker node and configures NAT on the node either via iptables or IPVS. The kube-proxy way of performing networking address translation of the packets in the cluster can be quite resource intensive especially at larger scales, which may impact the network throughput and latency. Cilium provides an eBPF based alternative to iptables and IPVS mechanisms implemented by kube-proxy with the promise to reduce CPU utilization and latency, improve throughput and increase scale.  As shown on the graph below, with the eBPF kube-proxy replacement, the HTTP request latency stays almost constant by increasing the number of Kubernetes services in the cluster. That is not the case for the iptables kube-proxy mode, which has scaling issues: ![HTTP request latency with eBPF and kube-proxy](/static/cilium-cni-integration-in-kubermatic-kubernetes-platform-http-request-latency-with-ebpf-and-kube-proxy.png) (Source: https://cilium.io/blog/2019/08/20/cilium-16) With Cilium eBPF kube-proxy replacement, the destination NAT happens at the socket level, before the network packet is even built by the kernel. The first packet to leave the client pod already has the right destination IP and port number, and no further NAT happens on its way to the destination pod. That means that the kube-proxy component does not even need to run on the worker nodes. ![Network-based vs. socket-based load balancing](/static/network-based-vs.-socket-based-load-balancing-cilium-cni-integration-in-kkp-blogpost.png) (Source: <https://cilium.io/blog/2019/08/20/cilium-16>) #### Advanced Security Apart from standard Kubernetes network policies working on layer 3, Cilium also uses its identity-aware and application-aware visibility to enable both DNS-based policies (e.g. allow/deny access to *.google.com) and application-based policies (e.g. allow/deny HTTP GET /foo). With the recently released Tetragon project security observability is also possible to monitor and detect process and syscall behavior. #### Advanced Networking Features Besides the already described benefits, eBPF allows Cilium to implement many more advanced networking features. These might help with the future evolution of KKP in the networking area. KKP team members are actively evaluating them for integration in future KKP releases. The features that got our interest and may be integrated with KKP at some later point include: * IPv6 / Dual-Stack support * Native support for LoadBalancer services with BGP * Sidecarless eBPF-powered Service Mesh * Multi-cluster connectivity with Cilium Cluster Mesh * Transparent Encryption #### Great Community Support Last but not least, a very important benefit of CIlium CNI is its wide adoption across the cloud-native community. Cilium is a CNCF incubation level project, has hundreds of contributors from different parties and has been chosen as the CNI of choice by many big public cloud providers. This assures that you will not be left alone with your issues, and potential bugs can be fixed very promptly. ## **Benefits for Cilium Users** By Integration of Cilium into Kubermatic Kubernetes Platform, Cilium gets an easy way of deployment into any of the KKP-supported infrastructure providers in cloud, on-premises or on edge. The supported infrastructure providers include: * AWS * Google Cloud * Azure * OpenStack * VMWare vSphere * Open Telekom Cloud * DigitalOcean * Hetzner * Alibaba Cloud * Equinix Metal * KubeVirt * Kubeadm Since Kubermatic Kubernetes Platform also manages the necessary infrastructure setup, starting a new Kubernetes cluster with Cilium CNI in any of the above mentioned providers is just a matter of a few minutes. Even in hybrid cloud provider scenarios with clusters scattered across different providers, the whole setup can be managed from the single self-service web portal and the end user experience is always the same. By leveraging [Cluster-API](https://github.com/kubernetes-sigs/cluster-api) and Kubermatic [machine-controller](https://github.com/kubermatic/machine-controller), the whole lifecycle of the worker nodes running on any cloud provider can be managed declaratively via Kubernetes Custom Resources, which helps to avoid vendor lock-in. ## **Lab: Deploying KKP Cluster With Cilium CNI and Exploring the Traffic** Now let's check out how this looks in real life: let's deploy a new KKP cluster with Cilium as the CNI! When creating a new cluster in KKP wizard, Cilium CNI and eBPF proxy mode can be selected on the Cluster Details page: ![Network configuration with Kubermatic Kubernetes Platform](/static/network-configuration-with-kubermatic-kubernetes-platform-cilium-cni-integration-in-kkp-blogpost.png) Few minutes later, after the cluster is deployed, you can observe the running pods in the kube-system namespace. As you can see, since we selected the eBPF proxy mode, kube-proxy is not deployed as service load-balancing is performed by cilium: ``` $ kubectl get pods -n kube-system NAME READY STATUS RESTARTS AGE cilium-nh9l4 1/1 Running 0 2m51s cilium-operator-5757cd4d9f-mtsqp 1/1 Running 0 5m39s coredns-767874cf84-9grjx 1/1 Running 0 5m39s coredns-767874cf84-xpwl5 1/1 Running 0 5m39s konnectivity-agent-69df85675-mft5d 1/1 Running 0 5m39s konnectivity-agent-69df85675-rhzjg 1/1 Running 0 5m39s metrics-server-7c94595b7c-7qq7s 1/1 Running 0 5m39s metrics-server-7c94595b7c-lkkwg 1/1 Running 0 5m39s node-local-dns-b4k9g 1/1 Running 0 2m51s user-ssh-keys-agent-bwgkg 1/1 Running 0 2m51s ``` Note that you can not see any kubernetes control plane components like apiserver or etcd in the cluster. Those are running in the [Seed cluster](https://docs.kubermatic.com/kubermatic/v2.20/architecture/) of the Kubermatic platform and are not visible for cluster end-user. Konnectivity-agent is the component which connects the worker nodes with the remote k8s control plane running in Seed. Next, we can enable the Hubble addon for network observability. To do that via the KKP web user interface, select the Addons tab on the Cluster Details page, click on the “Install Addon” button and select “hubble”: ![Install Hubble Addon with Kubermatic Kubernetes Platform ](/static/install-hubble-addon-with-kubermatic-kubernetes-platform-.png) Few moments later, you can see that Hubble components are now running in the cluster as well: ``` $ kubectl get pods -n kube-system NAME READY STATUS RESTARTS AGE cilium-nh9l4 1/1 Running 0 4m3s cilium-operator-5757cd4d9f-mtsqp 1/1 Running 0 6m51s coredns-767874cf84-9grjx 1/1 Running 0 6m51s coredns-767874cf84-xpwl5 1/1 Running 0 6m51s hubble-generate-certs-4a617efdba-spd4n 0/1 Completed 0 44s hubble-relay-56d45f97f8-rcc4s 1/1 Running 0 44s hubble-ui-54fb86b9f4-6gtk7 3/3 Running 0 44s konnectivity-agent-69df85675-mft5d 1/1 Running 0 6m51s konnectivity-agent-69df85675-rhzjg 1/1 Running 0 6m51s metrics-server-7c94595b7c-7qq7s 1/1 Running 0 6m51s metrics-server-7c94595b7c-lkkwg 1/1 Running 0 6m51s node-local-dns-b4k9g 1/1 Running 0 4m3s user-ssh-keys-agent-bwgkg 1/1 Running 0 4m3s ``` It is now possible to connect to the Hubble UI either using the `cilium hubble ui` CLI, or port-forwarding to it manually, e.g. by: `kubectl port-forward -n kube-system svc/hubble-ui 12000:80` and navigating to the <http://localhost:12000> address in your web browser: ![ Add the Hubble UI](/static/add-the-hubble-ui-cilium-cni-integration-in-kkp-blogpost.png) Even without installing the Hubble addon in KKP, it is still possible to manually execute into the cilium pods running in the cluster and and Hubble to observe the traffic via hubble CLI, e.g.: ``` $ kubectl exec -it cilium-nh9l4 -n kube-system -c cilium-agent -- hubble observe ``` ``` May 24 15:12:35.302: 172.25.0.53:40086 <- kube-system/metrics-server-7c94595b7c-7qq7s:4443 to-stack FORWARDED (TCP Flags: SYN, ACK) May 24 15:12:35.302: 172.25.0.53:40086 -> kube-system/metrics-server-7c94595b7c-7qq7s:4443 to-endpoint FORWARDED (TCP Flags: ACK) May 24 15:12:35.303: 172.25.0.53:40086 -> kube-system/metrics-server-7c94595b7c-7qq7s:4443 to-endpoint FORWARDED (TCP Flags: ACK, PSH) May 24 15:12:35.307: 172.25.0.53:41996 <- kube-system/metrics-server-7c94595b7c-lkkwg:4443 to-stack FORWARDED (TCP Flags: ACK, PSH) May 24 15:12:35.310: 172.25.0.53:41996 -> kube-system/metrics-server-7c94595b7c-lkkwg:4443 to-endpoint FORWARDED (TCP Flags: ACK, FIN) May 24 15:12:35.310: 172.25.0.53:41996 <- kube-system/metrics-server-7c94595b7c-lkkwg:4443 to-stack FORWARDED (TCP Flags: ACK, FIN) May 24 15:12:35.310: 172.25.0.53:41996 -> kube-system/metrics-server-7c94595b7c-lkkwg:4443 to-endpoint FORWARDED (TCP Flags: ACK) May 24 15:12:35.311: 172.25.0.53:40086 <- kube-system/metrics-server-7c94595b7c-7qq7s:4443 to-stack FORWARDED (TCP Flags: ACK, PSH) May 24 15:12:35.313: 172.25.0.53:40086 -> kube-system/metrics-server-7c94595b7c-7qq7s:4443 to-endpoint FORWARDED (TCP Flags: ACK, FIN) May 24 15:12:35.314: 172.25.0.53:40086 -> kube-system/metrics-server-7c94595b7c-7qq7s:4443 to-endpoint FORWARDED (TCP Flags: RST) ``` ## **Summary** By leveraging Cilium and Kubermatic Kubernetes Platform, users can benefit from advanced Kubernetes automation across any multi-cloud, on-prem and edge environment backended and secured by best-in-class networking connectivity. We hope you enjoy the ease with which the two integrate and always look forward to hearing your feedback and exchanging ideas via [Slack](https://app.slack.com/client/T0PGCH7CH) or [Github](https://github.com/kubermatic/kubermatic).      ## **Learn More** * Check out the [Cilium community page](https://cilium.io/) to learn more about eBPF-based networking  * Find [Cilium on Github](https://github.com/cilium/cilium) * [Get started with Kubermatic Kubernetes Platform](/demo/) Community Edition with our GitOps wizard --- ## PolicyReport CRD: Admission Control & Runtime - **URL:** https://www.kubermatic.com/resources/policyreport-crd-manage-admission-control-runtime-scan-reports/ - **Date:** 2024-03-21 - **Description:** Get different views on the Kubernetes policies incl. kube-bench, KubeArmor, Kyverno, and Trivy to produce standardized policy reports. # PolicyReport CRD — Manage Admission Control, Runtime, & Scan Reports! ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Learn how to easily manage policy results across admission controls, runtime, and vulnerability Policies help secure and automate Kubernetes. To standardize and simplify the management of policy reports across multiple tools, the Kubernetes Policy WG created a reusable PolicyReport Custom Resource Definition (CRD). In this session, Anushka, Mritunjay, and Stephen who are all LFX mentorship graduates were discussing the PolicyReport CRD and demonstrating adapters for policy and verification engines like Falco, kube-bench, KubeArmor, Kyverno, and Trivy to produce standardized policy reports. You’ll learn about the Policy Reporter, a Web UI with dashboards for policy reporting and integrations with Slack, Discord, Grafana, Teams, and Elasticsearch. Plus, you will see how to easily manage policy results across admission controls, runtime, and vulnerability scanning leveraging the powerful CRD capabilities of Kubernetes. **Speakers: Mritunjay Sharma (HackerRank), Anushka Mittal (Ramaiah Institute of Technology), Frank Jogeleit (Lovoo GmbH) and Stephen Adeniyi (Kubermatic)** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Kubernetes SIG UI Introduction and Updates - **URL:** https://www.kubermatic.com/resources/kubecon-europe-2022-kubernetes-sig-ui-introduction-and-updates/ - **Date:** 2022-12-01 - **Description:** Get insights about the Kubernetes Dashboard developed by the SIG UI. # Kubernetes SIG UI Introduction and Updates ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## What's new from the SIG UI and the Kubernetes Dashboard? SIG UI is the special interest group developing Kubernetes Dashboard. In this session the SIG UI leads will provide an overview of what was accomplished over the past year, including new views, functions, internationalizations, leadership changes etc. They will also share plans for the upcoming releases. The session will conclude with an open discussion and Q&A. **Speaker: Shu Muto (NCE), Marcin Maciaszczyk (Kubermatic) and Sebastian Florek (Kubermatic)** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Separation of Orchestration & Computation in KubeEdge - **URL:** https://www.kubermatic.com/resources/separation-of-orchestration-computation-in-kubeedge/ - **Date:** 2022-12-01 - **Description:** Understand how KubeEgde's cloud and edge components work and why this makes it the most compelling edge computing platform currently. # Separation of Orchestration & Computation in KubeEdge ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Understand why and how the features in KubeEdge make the CNCF project the most flexible edge computing platform With the advent of 5G, the era is going through the exciting phase of bringing Cloud Computing to Edge, with Businesses working on finding an ideal solution to meet their specific demands depending on their reality, use case, and scale.You’ve probably heard about KubeEdge - Kubernetes Native Edge Computing Framework (a CNCF Incubation project).One of the features which makes it a more flexible edge computing platform is making the separation of Orchestration capability in cloud and compute functionality in edge with separate cloud and edge core modules. Thus making it scalable and extendable on the cloud and at the same time, the edge can work in offline mode with optimizing resource utilization making it cost-effective. In this presentation, you will learn about how KubeEgde’s Cloud and Edge Components work, and why this makes it the most compelling edge computing platform currently, based on Kubernetes! **Speaker: Harshita Sharma, Software Engineer at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## KubeCon Europe 2022: Kubernetes on Manufacturing Line - **URL:** https://www.kubermatic.com/resources/kubecon-europe-2022-running-kubernetes-on-a-manufacturing-line/ - **Date:** 2024-03-21 - **Description:** Rewatch our KubeCon live talk and learn how to deliver industry 4.0 with Kubernetes on edge. # KubeCon Europe 2022: Running Kubernetes on a Manufacturing Line ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Deliver operations despite security breaches with Kubernetes on edge Imagine your production line is controlled by services running in your datacenters’ Kubernetes clusters. You have facilities in locations all over the world. You provide a managed service with an uptime SLA. Suddenly, there is an issue with the internet connection. Or security is shutting down all connections to defend against a cyberattack. And **your production line must keep working because downtime (always) costs money**! This was the challenge to solve, and we did! In this recording, you will learn about the obvious and non-obvious challenges of cloud native adopters in the industry 4.0 sector, including some true edge computing cases. **Speakers: Mario Fahlandt, Professional Service Engineer (Kubermatic) & Tobias Schneck Principal Software Architect (Kubermatic)** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Careers - **URL:** https://www.kubermatic.com/company/careers/ - **Date:** 2026-07-02 - **Description:** Check out all the job openings and apply for a great career ahead. Kubermatics provides endless opportunities that help in multi-cloud and edge operations. # Let’s Bring Power Through Automation. Everywhere. Together. [See All Open Positions](https://kubermatic.bamboohr.com/careers) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## How We Work Here at Kubermatic, we want to build a culture that inspires and supports our employees as they further their careers. If you’re looking for an environment where your input is valued every day and where you can help IT teams worldwide achieve power through automation, then this is the place to be! [See All Open Positions](https://kubermatic.bamboohr.com/careers) [Join Our BDR Team](/company/careers/join-our-bdr-team/) ![We are hiring](/static/we-are-hiring.png) ## What Is Kubermatic? At Kubermatic, we empower organizations worldwide to fully automate their Kubernetes and cloud native operations across multi-cloud, edge and on-prem. As a core contributor to the Kubernetes project, we develop software solutions and provide professional services to safely navigate the cloud native transformation. They say you enjoy what you do well; our customer success stories are the proof of our commitment to them and everyone at Kubermatic that contributes to our achievements every day. We are a dynamic front runner in our industry today, with leading enterprises like Lufthansa, Bosch, Siemens, and T-Systems trusting in us with their cloud native journey. [Read More About Our Story](/company/about-kubermatic/) ## What It’s Like to Work at Kubermatic We could say a lot here, but let’s listen to those who know best – our employees:) New challenges on a daily basis, the freedom to choose your own areas of speciality and development, flexible working hours and being involved and engaged in Kubernetes are but a few of the reasons why working for Kubermatic is great. **Christoph M.** Development ![Christoph M.](/static/christoph.png) Kubermatic gives its employees the opportunity to grow and develop. What I cherish most is the very trusting and appreciative relationship with each other – not only with other team members but also with our direct supervisors. Each employee is seen as a specialist in his or her field, and each employee’s contribution is important to the company. We know that we can rely on each other and that everyone gives their best to move the company forward. **Stefanie D.** Accounting ![Stefanie D.](/static/steffi.png) Kubermatic offers me a lot of freedom with respect to tooling and time management and working from home allows me to play an important role in my kids’ lives. I like the nerdiness of the company and working with smart people around the world, on the tech topics I care about. **Hubert S.** Professional Services ![Hubert S.](/static/hubert.png) ## What We Care About We truly believe that we can only achieve #powerthroughautomation if we take personal and professional growth as seriously as business growth. That’s why we defined a strong set of core values to help us accomplish our goals together. #1 ### We get things done Getting things done to me means taking action and being present. Sometimes it’s tough to focus because of the environment. That happens. But we still love what we do; customers and investors really can tell the difference. Dirk W. (Finance) #2 ### We are innovators When I think of innovation, I think of small things. Let’s think of a car for example. The first car was terrible. The seats were made of wood, the car was smelly and noisy. But with many, many years of progress and many, many smaller innovations and inventions, we finally got heated seats. That’s innovation. It’s how we work here and it’s very rewarding. Christoph M. (Development) #3 ### We value differences When I think of the key qualities our future employees should have, one of them is to encourage and augment the differences that we all bring to the table. For me it’s crucial that we listen to the input from all of our dev team members and that we don’t try to enforce or control something and rather embrace, incorporate and move forward together. It’s a huge pleasure for me to work with people from so many different countries and learn about various cultures, perspectives and the richness of this diversity. Sascha H. (Product) #4 ### We are optimists We know that we have great, cool products and we know that the customers have a real need. As Inside Sales, we act with self-confidence and a positive attitude. And even though we have to take setbacks, we always think positive and stay on the ball, we motivate ourselves and improve together as a team. Because that’s how we bring in customers and achieve outstanding results. Michael N. (Sales) #5 ### We treat our customers like partners If as a company we want long term, sustainable and personal relationships, then we absolutely need to regard our customers as partners. Why? Well, partnerships are made up of many important elements, but there are two key ones: Trust and empathy. We trust in our partners to make the right decisions, not for an individual but for what’s in the best interest for both and empathy enables us to always keep their needs in mind. Werner C. (Professional Services) #6 ### We are community-driven Having pizza and beer together with other cloud native enthusiasts is fun. But the more important part of being community-driven is to share experiences and discuss different approaches. It’s beneficial for both the community and our company. Living the open source approach, we strongly believe that we can solve problems better together and develop more innovative solutions as a result. Caro K. (Marketing) ![People celebrates at the desk](/static/people-celebrates-at-the-desk.jpg) ## Where We Work Working from home, at the beach, in the mountains, at our office in the beautiful city of Hamburg or hybrid – it’s your choice! ![rhombus mask](/images/rhombus-mask.svg) ![Workdesk](/images/photos/workdesk.jpg) ![rhombus mask](/images/rhombus-mask.svg) ![Beach photo](/images/photos/beach-photo.jpg) ![rhombus mask](/images/rhombus-mask.svg) ![Dolomite mountains](/images/photos/dolomite-mountains.jpg) ![rhombus mask](/images/rhombus-mask.svg) ![rhombus mask](/images/rhombus-mask.svg) We love being a globally distributed team – what will be the next country to mark? Map of the countries where our employees are working. Please approve the necessary category of cookie to see it. ## How We Support You to Be the Best ‘You’ That You Can Be We believe that people who do great work should receive the best possible support. We want our employees to feel like they belong and that they are well taken care of. It’s why we do our very best to create an inclusive culture where people can realize and share their passions both at and away from work. We also know that it’s not all about benefits and perks, but they’re important, too. ![Star](/images/icons/star.svg) ## Come As You Are We value diversity and individuality over conventionality and perfect CVs. ![Globe](/images/icons/globe.svg) ## Remote First We are looking to grow our remote team worldwide. ![Timer](/images/icons/timer.svg) ## Flexible Working Arrangements Design your career to fit your personal life, not the other way around. ![People](/images/icons/people.svg) ## Strong Community Involvement Contribute to our community conferences, meetups and open source projects. ![Bulb](/images/icons/bulb.svg) ## Hackathons & Onsites Meet and exchange ideas with your colleagues at our company events. ![Square cap](/images/icons/square-cap.svg) ## Never Stop Learning We encourage you to go to conferences and meet like-minded people to continuously expand your knowledge. ![Chat](/images/icons/chat.svg) ## Flat Hierarchy and Feedback We work in an open, friendly environment and keep our communication lines accessible, short and efficient. ![Double heart](/images/icons/double-heart.svg) ## Free Yoga Classes Start your Friday morning with some Vinyasa exercises to harmonize your body and soul and “flow” with your teammates through the day and into the weekend. ## Kubermatic Hangouts We love team & community events – meetups, our own conferences, afterworks, etc. Take a look :) ![](/static/careers-slide-1.jpg) ![](/static/careers-slide-2.jpg) ![](/static/careers-slide-3.jpg) ![](/static/careers-slide-4.jpg) ![](/static/careers-slide-5.jpg) ![](/static/careers-slide-6.jpg) ## What Employees Are Saying ![white star](/images/icons/white-star.svg) ![white star](/images/icons/white-star.svg) ![white star](/images/icons/white-star.svg) ![white star](/images/icons/white-star.svg) ![white star](/images/icons/white-star.svg) ### 4.8 98% of Employees on Glassdoor Recommend Kubermatic [Read Our Reviews](https://www.glassdoor.de/Bewertungen/Kubermatic-Bewertungen-E3924901.htm) --- ## Running Kubernetes on a Production Line - **URL:** https://www.kubermatic.com/resources/running-kubernetes-on-a-production-line/ - **Date:** 2022-12-01 - **Description:** In this video, you'll learn about the obvious and non-obvious challenges of cloud native adopters in the industry 4.0 sector. # Running Kubernetes on a Production Line ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Keep your production line up and running with Kubernetes on edge! You couldn’t make it to KubeCon Europe 2022 but don’t want to miss out on the really good talks? Great news – here comes your chance to rewatch Mario’s and Tobi’s wild journey on running Kubernetes on a production line. Imagine your production line is controlled by services running in your datacenters’ Kubernetes clusters. You have facilities in locations all over the world. You provide a managed service with an uptime SLA. Suddenly, there is an issue with the internet connection. Or security is shutting down all connections to defend against a cyberattack. And your production line must keep working because downtime (always) costs money! This was the challenge to solve, and we did! In this session, you will learn about the obvious and non-obvious challenges of cloud native adopters in the industry 4.0 sector, including some true edge computing cases. Speakers: Mario Fahlandt, Professional Service Engineer (Kubermatic) & Tobias Schneck Principal Software Architect (Kubermatic) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## My Journey to Motherhood at Kubermatic - **URL:** https://www.kubermatic.com/blog/my-journey-to-motherhood-at-kubermatic/ - **Date:** 2026-05-07 - **Description:** Our dear colleague and new mom Dorota tells how she combines her professional and private goals. - **Categories:** Company - **Tags:** Announcements - **Authors:** Dorota Mikulska I am a woman, a wife, a mother, and a successful professional among many things and I have a story to tell about my journey to motherhood during a global pandemic. My first daughter came just before the pandemic rolled out across the world which brought every expected challenge, including how to navigate this journey with balancing work and life. Shortly before my first child celebrated her second birthday, my second daughter was born when the pandemic limitations were still quite strict which was undoubtedly a difficult time for everyone. My story focuses on how I traversed every aspect of claiming my position as a mother, wife and a professional. In this blog post you will find out how the engagement of the management at work helped me to find a solution for work-life balance whilst keeping me relevant in my industry. I joined Kubermatic in early 2019 and back then it was a small start-up with 25 employees. Kubermatic is like a club for true board game fans – people not only share their interests but also support each other and put a lot of effort into their hobby. The supportive nature of the company ethos, towards both the users of the platform and the staff who run it was evident to me. I happily worked there so when one of the most defining moments of my life happened and I saw two positive lines on a pregnancy test. Instinctively I knew I could trust that the right thing would be done by me all the way through to my due date. ## **And All of the Sudden Everything Changes** On a profound personal level the focus immediately was about the factors around my pregnancy and planning for the future. This was aligned with delivering the requirements that work required until the time would come for me to depart. My husband and myself knew that these stages would be physically and mentally hard, with the absolute recognition of how  painful childbirth could be for me. It was heavily on my mind as to how to approach this conversation with my managers and colleagues; ultimately I would be leaving for a while. Especially as I, similarly to many other women, was worried about the possible reaction upon sharing my announcement and how I would be perceived by the colleagues whilst being pregnant and taking full maternity leave. When I did approach the management team I was met with an entirely positive and respectful approach, which allayed my fears instantly. I was allowed to be my own person with my own set of circumstances along with a deep understanding towards my family needs. Bear in mind that my first born was the first Kubermatic baby meaning no other employee before me was on maternity leave during their tenure in the company. I began to understand that I was not the exception to the rule in how the company supported people with their professional and personal choices. From conversations I gathered that I was not unique in how Kubermatic accommodated for an individual to have a leave of absence from work. This pleased me greatly. ## **Combining the Two Worlds** A number of examples still resound with me as to the difference between a flexible employer as opposed to one who is not. As a new parent you always struggle, irrespective of the flexibility shown to you. To me, it was quite significant to ‘indulge’ in swimming classes for my baby, which is a brilliant way to bond with a new child. I felt that working around my pre planned schedule to allow these things to happen was absolutely the symbiotic nature I agreed to with work and my home life. Moreover I had a meeting with my manager and colleagues  to discuss my meaningful return to work, which strongly emphasised that my happiness was a key focus of both our priorities. I tried out working part time for the first week being back  and when I gathered that my child accepts the care well, I initiated a smooth switch to working full time. I felt very respected in the whole transition process. Becoming a mother is a transition in life. It can also be an awful prospect when approaching a boss, the management or the company to discuss this new development. It is genuinely scary. I have always commanded respect, professionalism and creativity wherever I have been, so the second I changed that by becoming a mother seems to compromise all of these tenants. I disagree. It can be everything I want it to be. I am so glad through communication and grace I confirmed my standing with my company so I implore you to do the same. We all have multiple facets to our lives, be proud of all of them. --- ## Kubermatic April News - **URL:** https://www.kubermatic.com/blog/kubermatic-april-news/ - **Date:** 2026-05-07 - **Description:** Get your 20% discount voucher for KubeCon Europe and save your seat for ContainerDays in September! - **Categories:** Company - **Tags:** Announcements - **Authors:** Sebastian Scheele April is always a special month for my co-founder Julian and me. Because it's Kubermatic's birthday month. Our baby turned 6 this year and admittedly, we sometimes still can't quite believe it: Our gut feeling that Kubernetes could be a big thing actually became true. Now in 2022, we’re proud that Kubermatic is a **100% open core company** with more than **100 team members, strong partners, trusted investors and a huge community** along our side sharing our vision of **bringing #powerthroughautomation everywhere**. A big thank you to all of you! \[Potentially a Smiley] If you want to read more about our crazy rollercoaster ride, check out some of our [latest achievements](https://cxwn804.na1.hubspotlinks.com/Ctc/LW+113/cxWn804/VWpV5S3pDQlSW79RTBP2m4y-RV9TLwZ4JqvQrN4jRWbX3lSbtV1-WJV7CgLh9W6FTMnJ2zbPdJW3VFXs-8vbstDW6yJPfr92swYWW13xVmX7FkcR3W68tRTn2QBmK1N9gqbzwsmzFvW7Hw5jz2fNxl0W30989t8P_5B_W4XL1M_1Z8rc8W91JP6y30Gp8xW3c03zV8QMMtXW8F-cdm5LcYzTW82C95k6wW1SlW4xlr_z3Q5dlLW8Xvcky4y2-B2W4CyKTS540ct3W7XZjn52w0hB2VBRtx_4sM9WwW4hMfbZ1P1Z0cVvWW0W74fY-139lB1). And if you are curious what else has happened since the last update, have a look at the resources we put together for you. ## **Kubermatic at KubeCon Europe 2022** We’re super excited to meet at KubeCon Europe; in person in Valencia or virtually. Together with our partners SVA, Nutanix and Difinative we bring you 4x #powerthroughautomation.  Make sure to pass by our booth with lots of fun stuff planned. ## **No Ticket Yet?** As a sponsor, we do have a limited amount of 20% vouchers for the onsite conference and free vouchers for the virtual event. Send us an email and let us know whether you want to join us onsite or online. First come, first serve! If you want to get a voucher, send us an email to **marketing@kubermatic.com** ## Exclusive Demo With Damian Marquez  ...and your chance to win one out of 6 Nintendo Switch 😎 [Schedule Your 1:1 Meeting](https://calendly.com/damian-marquez) ## Talk: Running Kubernetes in a Manufacturing Line – What Could Possibly Go Wrong? 📅 May 20, 2022 at 4:55 PM CEST 📢 Mario Fahlandt & Tobias Schneck (Kubermatic) [Join the Talk](https://kccnceu2022.sched.com/event/ytuM) ## **Talk: PolicyReport CRD — Manage Admission Control, Runtime, and Scan Reports!** 📅 May 20, 2022 at 4:55 PM CEST 📢 Mritunjay Sharma (HackerRank), Anushka Mittal (Ramaiah Institute of Technology), Frank Jogeleit (Lovoo GmbH) and Stephen Adeniyi (Kubermatic) [Join the Talk](https://kccnceu2022.sched.com/event/ytuV) Talk: Kubernetes SIG UI Introduction and Updates 📅 May 19, 2022 at 3:25 PM CEST 📢 Shu Muto (NEC), Sebastian Florek (Kubermatic) and Marcin Maciaszczyk (Kubermatic) [Join the Talk](https://kccnceu2022.sched.com/event/ytpx) ## Talk at Kubernetes on Edge Day: Separation of Orchestration and Computation in KubeEdge, Understand the Why and How 📅 May 17, 2022 at 2:10 PM CEST 📢 Harshita Sharma (Kubermatic) [Join the Talk](https://kubernetesonedgedayeu22.sched.com/event/zsAT) ## Kubermatic Blog * [Striving for the Fastest Response Times in Kubernetes Clusters](https://www.kubermatic.com/blog/striving-for-the-fastest-response-times-in-kubernetes-clusters/) * [A Guide to the Kubernetes Ingress Controllers](https://www.kubermatic.com/blog/a-guide-to-the-kubernetes-ingress-controllers/) * [Why We Decided to Support External Kubernetes Clusters via API](https://www.kubermatic.com/blog/why-we-decided-to-support-external-kubernetes-clusters-via-api/) [Discover Our Blog](https://www.kubermatic.com/blog/) ## Kubermatic Resources ### Cheatsheet: A Brief “Brief” for C-Level Executives on Kubernetes Adapt or die is probably truer than ever before when we speak about software centric organizations. Because of this, Kubernetes has seen an extraordinary rate of adoption in large organizations worldwide and it’s become a very hot topic with C-level Executives. So let’s get you armed for your next discussion about this technology;) [Download Our Brief](https://www.kubermatic.com/resources/a-brief-brief-for-c-level-executives-on-kubernetes/) ## Events & More ### Save Your Early Bird Ticket for ContainerDays 2022 📅 September 5-7, 2022 **📍** Hamburg and online You can’t make it to KubeCon but you are yearning for a fun in-person conference this year? Then **ContainerDays (CDS) 2022** is your place to be! Europe’s flagship conference will offer you a great learning experience on **\#Kubernetes, #CloudNative, #DevOps, #GitOps, #EdgeComputing** and much more. This is your opportunity to meet and exchange with other cloud native enthusiasts from across the globe in person or virtually. Be quick – our early bird offer ends on May 31! Don’t miss your chance to only pay **€499 instead of the regular €599** for the onsite conference (Virtual tickets are for free). [Grab Your CDS Ticket](https://www.containerdays.io/tickets/) --- ## Kubermatic KubeOne for Edge Environments - **URL:** https://www.kubermatic.com/products/kubermatic-kubeone/edge/ - **Date:** 2026-03-17 - **Description:** Easily automate cluster operations on your edge and IoT environments by using one tool that works on every platform. # Kubermatic KubeOne for Edge Environments Kubermatic KubeOne provides an upstream Kubernetes cluster with full cluster lifecycle management of your Kubernetes clusters on the edge or in IoT deployments. [Contact Sales](/contact-sales/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## How Kubermatic KubeOne Covers All Your Edge Needs KubeOne is an open source cluster lifecycle management tool that takes the pain out of managing Kubernetes clusters. It creates and manages highly available ones on every environment, including edge computing environments such as IoT devices or remote locations with limited connectivity- all while improving responsiveness for users by optimizing their experience based upon location (availability), device capabilities etc., reducing bandwidth consumption at once! ## Want to learn more now? Pick a Provider [![VMware vSphere](/static/vmware-vsphere.svg)](/products/kubermatic-kubeone/edge/#vmware-vsphere "VMware vSphere") [![Static BareMetal](/static/baremetal-logo.png)](/products/kubermatic-kubeone/edge/#static-baremetal "Static BareMetal") [![ARM](/static/arm-logo.svg)](/products/kubermatic-kubeone/edge/#arm "ARM") ## Global Leaders Work With Kubermatic ![Siemens](/images/partners/8.png) ![T-Systems](/images/partners/t-systems-logo-grey.svg) ![Hilti](/images/partners/4.png) ![Allianz](/images/partners/Allianz.png) ![1&1](/images/partners/16.png) ![Bosch](/images/partners/5.png) ![Lufthansa](/images/partners/1.png) Jump to section [VMware vSphere](/products/kubermatic-kubeone/edge/#vmware-vsphere) [Static BareMetal](/products/kubermatic-kubeone/edge/#static-baremetal) [ARM](/products/kubermatic-kubeone/edge/#arm) ![VMware vSphere](/static/vmware-vsphere.svg) KubeOne for Edge Environments on vSphere creates highly available Kubernetes clusters on your edge environment. It’s a perfect fit for manufacturing, for example, where users are leveraging existing environments and upgrading them to cloud native technologies. KubeOne on vSphere Edge is built with operations in mind – it has been designed from the ground up to be easy-to-manage and scale as necessary. You can easily deploy clusters of any size that will scale up or down automatically based on your needs. And because we use cloud native standards you don’t have to worry about vendor lock-in – you can always move your workloads elsewhere if needed! ![Static BareMetal](/static/baremetal-logo.png) ## Static BareMetal KubeOne is a bare metal cluster lifecycle management tool that allows you to deploy highly available Kubernetes clusters on the edge. Thanks to KubeOne’s API-first design you can integrate your existing technology stack and upgrade it to cloud native. This enables rapid, cost-effective adoption of enterprise-grade cloud technologies without disruption or downtime. Edge computing has become an essential part of manufacturing and many other industries in which data needs to be processed in real time. KubeOne gives your company access to those resources right from your factory floor or field office without the need for costly Day 2 operations  by IT staff. The result? Reduced costs and increased productivity—making the future possible today! ![ARM](/static/arm-logo.svg) KubeOne is a container-native solution for edge environments. KubeOne uses ARM architecture so it can be deployed on any device from an edge router to a Raspberry Pi at the IoT gateway. In addition, KubeOne has been designed with an API-first approach that allows businesses to leverage their existing infrastructure without having to build something new or replace legacy systems that may not have cloud native capabilities. The versatility of KubeOne allows us to address the needs of a wide variety of clients; manufacturers who want a better way to manage their edge devices, retailers who need a scalable content delivery network, and many more! --- ## Kubermatic KubeOne for On-Prem - **URL:** https://www.kubermatic.com/products/kubermatic-kubeone/onprem/ - **Date:** 2026-02-27 - **Description:** Easily deploy your upstream Highly Available Kubernetes cluster on your own datacenter with our open source cluster lifecycle tool. # Kubermatic KubeOne for On-Prem Install, manage, and upgrade your cluster in your datacenter with a single command line tool. [Contact Us](/contact-us/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## How Kubermatic KubeOne Covers All Your On-Prem Needs Kubermatic’s KubeOne solution is the best in class for on premise infrastructure and containers. Whether you’re looking to build a hyperconverged, bare metal deployment or any other type of virtualization - we’ve got it covered with unmatched adaptivity! And at an affordable cost without compromising quality or performance too; this open source cluster lifecycle tool was created by our team just so enterprises can automate everything from deployment through management–allowing them time to only focus their efforts where they matter most: Growing business. ## Want to learn more now? Pick a Provider [![VMware vSphere](/static/vmware-vsphere.svg)](/products/kubermatic-kubeone/onprem/#vmware-vsphere "VMware vSphere") [![OpenStack](/static/openstack-logo.svg)](/products/kubermatic-kubeone/onprem/#openstack "OpenStack") [![Static BareMetal](/static/baremetal-logo.png)](/products/kubermatic-kubeone/onprem/#static-baremetal "Static BareMetal") ## Global Leaders Work With Kubermatic ![Siemens](/images/partners/8.png) ![T-Systems](/images/partners/t-systems-logo-grey.svg) ![Hilti](/images/partners/4.png) ![Allianz](/images/partners/Allianz.png) ![1&1](/images/partners/16.png) ![Bosch](/images/partners/5.png) ![Lufthansa](/images/partners/1.png) Jump to section [VMware vSphere](/products/kubermatic-kubeone/onprem/#vmware-vsphere) [OpenStack](/products/kubermatic-kubeone/onprem/#openstack) [Static BareMetal](/products/kubermatic-kubeone/onprem/#static-baremetal) ![VMware vSphere](/static/vmware-vsphere.svg) KubeOne is a cluster lifecycle management tool for deploying highly available clusters on your existing VMware vSphere infrastructure. It’s ideal for all businesses that need to integrate with existing technology stacks and upgrade to cloud native technologies while ensuring a high level of availability. KubeOne makes the process seamless, by providing automated deployment, configuration and Day 2 operations. ![OpenStack](/static/openstack-logo.svg) KubeOne is a cluster lifecycle management tool to deliver a highly available, fault tolerant Kubernetes cluster for your on-prem OpenStack environment. KubeOne is adaptable to the point that it can be deployed as a single node, as well as scaling to any size.Thanks to its API-first design, KubeOne makes it easy to upgrade your current environment to cloud native within a few minutes. It’s the best solution for any company looking to integrate their existing technology stack and move it into a cloud native infrastructure. ![Static BareMetal](/static/baremetal-logo.png) ## Static BareMetal KubeOne offers a reliable, highly available solution for on-prem environments with Static BareMetal. With KubeOne, you can run high availability Kubernetes clusters in your own environment without the need to change your current technology stack. If you\`re running an old operating system or using outdated hardware, we can turn that old infrastructure into a state-of-the-art cloud native environment so it works seamlessly with the rest of your stack and doesn’t require any changes to how you work or update your systems. --- ## Kubermatic KubeOne for the Cloud - **URL:** https://www.kubermatic.com/products/kubermatic-kubeone/cloud/ - **Date:** 2026-03-17 - **Description:** With our open source KubeOne, we empower your team to successfully deliver their project without wasting time and resources getting Kubernetes up and running. # Kubermatic KubeOne for the Cloud Pilot your Kubernetes project with our open source cluster lifecycle management tool by easily deploying your upstream HA Kubernetes cluster in minutes in the cloud on your chosen provider. [Contact Us](/contact-us/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## How Kubermatic KubeOne Covers All Your Cloud Needs KubeOne is a powerful, easy-to use tool for managing Kubernetes clusters on any provider. It automates the entire lifecycle of your infrastructure including installing, provisioning and upgrading with just one click! With KubeOne’s native support across multiple platforms like AWS, Azure, Digital Ocean, GCP, Hetzner Cloud, etc. you can be confident that this will work seamlessly in even more environments than before. ## Want to learn more now? Pick a Provider [![AWS](/images/logos/aws-logo.svg)](/products/kubermatic-kubeone/cloud/#aws "AWS") [![Azure](/images/logos/azure-logo.svg)](/products/kubermatic-kubeone/cloud/#azure "Azure") [![Google Cloud](/static/google-cloud-logo.svg)](/products/kubermatic-kubeone/cloud/#google-cloud "Google Cloud") [![Open Telekom Cloud](/images/logos/open-telekom-cloud-logo.png)](/products/kubermatic-kubeone/cloud/#open-telekom-cloud "Open Telekom Cloud") [![Alibaba Cloud](/static/alibaba-cloud-logo.svg)](/products/kubermatic-kubeone/cloud/#alibaba-cloud "Alibaba Cloud") [![Hetzner Cloud](/static/hetzner-logo.svg)](/products/kubermatic-kubeone/cloud/#hetzner-cloud "Hetzner Cloud") [![DigitalOcean](/images/logos/digitalocean-logo.svg)](/products/kubermatic-kubeone/cloud/#digitalocean "DigitalOcean") [![Equinix Metal](/static/equinix-metal-logo.svg)](/products/kubermatic-kubeone/cloud/#equinix-metal "Equinix Metal") ## Global Leaders Work With Kubermatic ![Siemens](/images/partners/8.png) ![T-Systems](/images/partners/t-systems-logo-grey.svg) ![Hilti](/images/partners/4.png) ![Allianz](/images/partners/Allianz.png) ![1&1](/images/partners/16.png) ![Bosch](/images/partners/5.png) ![Lufthansa](/images/partners/1.png) Jump to section [AWS](/products/kubermatic-kubeone/cloud/#aws) [Azure](/products/kubermatic-kubeone/cloud/#azure) [Google Cloud](/products/kubermatic-kubeone/cloud/#google-cloud) [Open Telekom Cloud](/products/kubermatic-kubeone/cloud/#open-telekom-cloud) [Alibaba Cloud](/products/kubermatic-kubeone/cloud/#alibaba-cloud) [Hetzner Cloud](/products/kubermatic-kubeone/cloud/#hetzner-cloud) [DigitalOcean](/products/kubermatic-kubeone/cloud/#digitalocean) [Equinix Metal](/products/kubermatic-kubeone/cloud/#equinix-metal) ![AWS](/images/logos/aws-logo.svg) KubeOne is a cluster lifecycle management tool for deploying and operating Kubernetes clusters on AWS cloud. KubeOne makes it easy to manage your Kubernetes clusters with deep integration and independence on AWS. With advanced options like AWS spot instances support, you achieve the best possible cost efficiency for your clusters in production. KubeOne is a full-stack solution that includes all of the components you need to deploy highly available clusters – from installation of kubeadm through monitoring, alerting and logging tools - so you don’t have to worry about anything except getting things done! ![Azure](/images/logos/azure-logo.svg) Have you ever wanted to deploy a highly available cluster on Azure? KubeOne is the solution for you. KubeOne is a full-stack software solution that was developed with Microsoft Azure in mind. Designed from the ground up it works perfectly alongside all of Azure\`s products and services, so that you can create an environment in which all of your applications will run smoothly and efficiently. KubeOne offers features like remote management, monitoring and troubleshooting to ensure that your deployment is seamless. Because it doesn’t lock customers into proprietary solutions, KubeOne is perfect for global enterprises that want to leverage the flexibility of cloud computing without sacrificing their existing investment in both hardware and software. ![Google Cloud](/static/google-cloud-logo.svg) KubeOne is an open source solution for deploying highly available clusters on the Google Cloud Platform. The KubeOne cluster lifecycle management tool supports existing environments and upgrades them to cloud native. With KubeOne you can spin up a cluster in minutes, scale it up or down as needed, and replace your legacy infrastructure with one that scales cost effectively while retaining its performance. The combination of KubeOne’s ease of use and integration with Google Cloud Platform provides consistency between public and private clouds, enabling businesses to modernize their infrastructure while developers build faster, regardless of the underlying environment. ![Open Telekom Cloud](/images/logos/open-telekom-cloud-logo.png) KubeOne is your best bet for deploying highly available Kubernetes clusters on Open Telekom Cloud (OTC). KubeOne is an easy-to-use CLI tool that leverages existing environments, so you can get started quickly. It also takes care of upgrades, making the transition to cloud native simple. The integration with OTC is very deep, with proven use cases that demonstrate a reduction in complexity by an incredible 20 times. This helps you deliver the best possible service to your customers while cutting costs in half or more! ![Alibaba Cloud](/static/alibaba-cloud-logo.svg) KubeOne is an easy-to-use, full-stack solution for deploying highly available clusters on Alibaba Cloud. It’s open source, so it’s free to download and use. KubeOne takes advantage of the flexibility of the Alibaba Cloud platform to provide a cost effective way to deploy mission critical applications with high availability and service level agreements (SLAs). Deploying your clusters via KubeOne helps you mitigate risk, save time and money, and focus on what matters most – running your business! ![Hetzner Cloud](/static/hetzner-logo.svg) KubeOne is a cluster lifecycle management tool for deploying highly available clusters on Hetzner Cloud. KubeOne delivers highly available clusters for production and makes it easy to upgrade your current environment to a high performance cloud native environment with minimal downtime. KubeOne and the Hetzner Cloud is the perfect combination, with an unbeatable price / performance ratio - optimized for scaling. You can use KubeOne to deploy large scale systems like Elasticsearch, Kafka or Cassandra on our cloud infrastructure. Or you can use it as an individual application host on the Hetzner Cloud with custom settings. There are many deployment options to suit any need! ![DigitalOcean](/images/logos/digitalocean-logo.svg) KubeOne is an open source CLI tool for deploying highly available clusters on Digital Ocean. With the KubeOne API and developer tools, you deploy container-based applications to production environments with minimal downtime. The intuitive API makes it easy for developers to build web apps or API backends on a robust infrastructure. KubeOne also provides CI/CD add-ons that speed up development and make it simpler than ever to learn the basics of cloud computing. With KubeOne, we deliver a software solution that makes sure your clusters are always online and able to handle traffic spikes, without any downtime due to upgrades or maintenance windows. ![Equinix Metal](/static/equinix-metal-logo.svg) KubeOne is the easiest way to deploy highly available clusters on Equinix Metal. KubeOne is a full-stack open source solution for deploying containers at scale and comes with an out-of-the-box integration with Equinix Metal. With KubeOne, you can effortlessly manage your workloads across multiple locations, while taking advantage of the unmatched global reach and connectivity ecosystem made possible by Equinix Metal. --- ## Kubermatic Kubernetes Platform for Edge Environments - **URL:** https://www.kubermatic.com/products/kubermatic-kubernetes-platform/edge/ - **Date:** 2026-02-27 - **Description:** Easily handle the constraints and scalability of edge computing with Kubermatic Kubernetes Platform and your preferred provider. # Kubermatic Kubernetes Platform for Edge Environments Automate operations of thousands of Kubernetes clusters across your chosen edge locations. ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## How Kubermatic Kubernetes Platform Covers All Your Edge Needs Kubermatic Kubernetes Platform (KKP) is a Kubernetes-based open platform for managing edge infrastructure and containers. It was designed to handle the constraints and scalability of edge computing, which often has resource limitations such as reduced bandwidth or processing power. KKP scales dynamically with your needs so you can start small and grow as needed without any downtime or data loss. You might use it to set up a single node that houses an application then scale out when demand increases. Or you could use it to run many different applications on one physical server simultaneously without having them interfere with each other’s resources. ## Want to learn more now? Pick a Provider [![VMware vSphere](/static/vmware-vsphere.svg)](/products/kubermatic-kubernetes-platform/edge/#vmware-vsphere "VMware vSphere") [![KubeVirt](/static/kubevirt-horizontal-color.png)](/products/kubermatic-kubernetes-platform/edge/#kubevirt "KubeVirt") [![Static BareMetal](/static/baremetal-logo.png)](/products/kubermatic-kubernetes-platform/edge/#static-baremetal "Static BareMetal") [![Dynamic BareMetal](/static/DynamicBareMetal-Logo.PNG)](/products/kubermatic-kubernetes-platform/edge/#dynamic-baremetal "Dynamic BareMetal") [![ARM](/static/arm-logo.svg)](/products/kubermatic-kubernetes-platform/edge/#arm "ARM") ## Global Leaders Work With Kubermatic ![Siemens](/images/partners/8.png) ![T-Systems](/images/partners/t-systems-logo-grey.svg) ![Hilti](/images/partners/4.png) ![Allianz](/images/partners/Allianz.png) ![1&1](/images/partners/16.png) ![Bosch](/images/partners/5.png) ![Lufthansa](/images/partners/1.png) Jump to section [VMware vSphere](/products/kubermatic-kubernetes-platform/edge/#vmware-vsphere) [KubeVirt](/products/kubermatic-kubernetes-platform/edge/#kubevirt) [Static BareMetal](/products/kubermatic-kubernetes-platform/edge/#static-baremetal) [Dynamic BareMetal](/products/kubermatic-kubernetes-platform/edge/#dynamic-baremetal) [ARM](/products/kubermatic-kubernetes-platform/edge/#arm) ![VMware vSphere](/static/vmware-vsphere.svg) Kubermatic Kubernetes Platform (KKP) is a container-based platform that seamlessly integrates with your existing VMware vSphere installation, allowing you to leverage edge cases for your manufacturing workloads inside your own facility. KKP\`s highly adaptable and resilient architecture ensures the best return on investment for your most innovative projects. With Kubermatic Kubernetes Platform, optimizing product development cycles has never been easier! ![KubeVirt](/static/kubevirt-horizontal-color.png) Kubermatic Kubernetes Platform supports Kubevirt in two ways, one of them is rather unconventional. We use KubeVirts unique feature set to split machines into smaller virtualized nodes that become worker nodes within the Kubernetes user cluster, so that utilization at the edge can be maximized. It saves a lot of additional management as everything is K8s native and provides state of the art technology. The classic way is running VMs on an edge node to support legacy software is of course possible with our integration and harmonizes your IT and OT infrastructure. ![Static BareMetal](/static/baremetal-logo.png) ## Static BareMetal Kubermatic Kubernetes Platform creates Kubernetes infrastructure on bare metal, allowing for the simplest configuration and deployment. The integration with existing environments is seamless, as it can be deployed into any environment that has network connectivity to another machine running Kubernetes. So you don’t have to worry about designing your infrastructure around the needs of Kubernetes, you can create it around what’s already there. Even better, all you need is the CLI and kubectl to get things up and running in minutes. Because we’re using bare metal rather than virtualization or containers, you also gain performance benefits due to increased CPU cores availability and RAM capacity per node - not just over provisioned nodes that can’t deliver when it’s most needed at the Edge. ![Dynamic BareMetal](/static/DynamicBareMetal-Logo.PNG) ## Dynamic BareMetal Kubermatic Kubernetes Platform (KKP) is a Kubernetes-based solution that allows you to orchestrate dynamic bare metal environments with all of the prerequisites for virtual machines, side by side workloads, and dynamic infrastructure allocation. So your business can adopt containers without having to buy new hardware or invest in expensive software licenses. You can make use of existing resources while leveraging the benefits of containerization at the edge. KKP’s unique architecture allows for optimal allocation of resources. Additionally, the management plane consumes a fraction of compute compared to any other platform. All of this is done with an intuitive UI combined with API access for mass deployment across multiple clusters. The platform provides a fully automated workflow that eliminates manual intervention and ensures high availability at all times. It also includes out-of-the-box support for third party tools such as Terraform, Ansible and Jenkins CI/CD. ![ARM](/static/arm-logo.svg) Kubermatic Kubernetes Platform (KKP) is the only solution in the market that integrates seamlessly with any ARM infrastructure. KKP on ARM for Edge gives you all of the features and benefits of a high-end datacenter, but in a cost efficient, power saving environment. You can leverage your existing investment by deploying KKP to your edge nodes - where they will still have full access to all enterprise level security, scalability and reliability. And because our platform was built from scratch using microservices architecture, you get an easy way to deploy software updates without downtime or service interruptions. --- ## Kubermatic Kubernetes Platform for On-Prem - **URL:** https://www.kubermatic.com/products/kubermatic-kubernetes-platform/onprem/ - **Date:** 2026-02-27 - **Description:** With Kubermatic Kubernetes Platform, you can handle hyperconverged, bare metal, as well as any type of virtualization and opt for unrivaled adaptability. # Kubermatic Kubernetes Platform for On-Prem Automate your on-prem operations with a single management UI and API enabling you to deliver the cloud native transformation immediately with Kubermatic Kubernetes Platform. ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## How Kubermatic Kubernetes Platform Covers All Your On-Prem Needs Kubermatic Kubernetes Platform is specifically designed and built for the needs of on premise infrastructure and containers. It handles hyperconverged, bare metal, as well as any type of virtualization and comes with unrivaled adaptability, resilience and pricing. The platform was created to provide enterprises with the best solution for their container management needs at an affordable cost without compromising quality or performance. ## Want to learn more now? Pick a Provider [![VMware vSphere](/static/vmware-vsphere.svg)](/products/kubermatic-kubernetes-platform/onprem/#vmware-vsphere "VMware vSphere") [![Nutanix](/static/nutanix-logo.svg)](/products/kubermatic-kubernetes-platform/onprem/#nutanix "Nutanix") [![OpenStack](/static/openstack-logo.svg)](/products/kubermatic-kubernetes-platform/onprem/#openstack "OpenStack") [![KubeVirt](/static/kubevirt-horizontal-color.png)](/products/kubermatic-kubernetes-platform/onprem/#kubevirt "KubeVirt") [![Static BareMetal](/static/baremetal-logo.png)](/products/kubermatic-kubernetes-platform/onprem/#static-baremetal "Static BareMetal") [![Dynamic BareMetal](/static/DynamicBareMetal-Logo.PNG)](/products/kubermatic-kubernetes-platform/onprem/#dynamic-baremetal "Dynamic BareMetal") ## Global Leaders Work With Kubermatic ![Siemens](/images/partners/8.png) ![T-Systems](/images/partners/t-systems-logo-grey.svg) ![Hilti](/images/partners/4.png) ![Allianz](/images/partners/Allianz.png) ![1&1](/images/partners/16.png) ![Bosch](/images/partners/5.png) ![Lufthansa](/images/partners/1.png) Jump to section [VMware vSphere](/products/kubermatic-kubernetes-platform/onprem/#vmware-vsphere) [Nutanix](/products/kubermatic-kubernetes-platform/onprem/#nutanix) [OpenStack](/products/kubermatic-kubernetes-platform/onprem/#openstack) [KubeVirt](/products/kubermatic-kubernetes-platform/onprem/#kubevirt) [Static BareMetal](/products/kubermatic-kubernetes-platform/onprem/#static-baremetal) [Dynamic BareMetal](/products/kubermatic-kubernetes-platform/onprem/#dynamic-baremetal) ![VMware vSphere](/static/vmware-vsphere.svg) With Kubermatic Kubernetes Platform and VMware vSphere, you get the best of both worlds – virtualization software for managing traditional server workloads plus powerful management tools for containers and Kubernetes. This hybrid approach gives you everything you need to modernize your IT environment without disrupting legacy apps or compromising security compliance requirements. ![Nutanix](/static/nutanix-logo.svg) Nutanix and Kubermatic Kubernetes Platform are a match made in heaven for on premise workloads. The hyperconverged infrastructure with state-of-the-art software of Nutanix aligns perfectly with Kubermatic Kubernetes Platform to manage container workloads in any hybrid scenario. With Nutanix, you can deploy virtualized or container based applications at scale, without sacrificing performance, availability or security – all from a single platform that integrates compute storage and networking as well as the latest open source technology. ![OpenStack](/static/openstack-logo.svg) Kubermatic Kubernetes Platform is a container management platform for managing large pools of compute, storage and networking resources on OpenStack. This means you can use the same set of APIs or KKP’s intuitive UI to manage your containers as well as your traditional virtual machines, all from a single pane of glass. Product combinations like this are ideal when you need more control over how your infrastructure is deployed, when it gets patched and what tools are being used with it. With Kubermatic Kubernetes Platform, we’ve taken care to ensure that users have access to everything they need in one place – whether that’s orchestration across multiple hosts or enforcing policies throughout the stack. ![KubeVirt](/static/kubevirt-horizontal-color.png) Running side by side workload of VMs and containers is the original reason behind KubeVirt. The advantage becomes apparent when you want to manage containers and virtual machines simultaneously and in a similar fashion. Kubermatic Kubernetes Platform integrates KubeVirt in the best possible way to add to these benefits and eases the installation and configuration of KubeVirt itself. Run crucial workloads in traditional VMs and work on the next generation software simultaneously. Creating a comfortable transition environment for your most demanding workloads Kubermatic Kubernetes Platform creates secure projects for side by side workloads. ![Static BareMetal](/static/baremetal-logo.png) ## Static BareMetal Kubermatic Kubernetes Platform is an enterprise-grade software solution that unifies the management of on-premises and public cloud resources. It combines the power of Kubernetes with unique features for managing bare metal environments to provide you with an unmatched price-to-performance ratio. Kubermatic Kubernetes Platform is all you need to run supercomputing farms on  Kubernetes. ![Dynamic BareMetal](/static/DynamicBareMetal-Logo.PNG) ## Dynamic BareMetal Kubermatic Kubernetes Platform is a Kubernetes-based solution that allows you to orchestrate dynamic bare metal environments with all of the prerequisites for virtual machines, side by side workloads and dynamic infrastructure allocation. Your business can adopt containers without having to buy new hardware or invest in expensive software licenses. You can make use of existing resources while leveraging the benefits of containerization, all done with an intuitive web interface combined with API access for mass deployment across multiple clusters. --- ## Kubermatic Kubernetes Platform for the Cloud - **URL:** https://www.kubermatic.com/products/kubermatic-kubernetes-platform/cloud/ - **Date:** 2026-02-27 - **Description:** Easily operate thousands of Kubernetes clusters on your preferred cloud provider with Kubermatic Kubernetes Platform. # Kubermatic Kubernetes Platform for the Cloud Automate operations of hundreds of Kubernetes clusters across any hybrid or multi-cloud environment with Kubermatic Kubernetes Platform. ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## How Kubermatic Kubernetes Platform Covers All Your Cloud Needs The Kubermatic Kubernetes Platform (KKP) is designed for scale beyond just cloud, exceeding usual cloud implementation in terms of management overhead, scalability and adaptability. Work with hyperscalers and local cloud providers with the same interface and principles. Thus reducing complexity as KKP configures your cloud environments standardized for optimal performance and security. ## Want to learn more now? Pick a Provider [![AWS](/images/logos/aws-logo.svg)](/products/kubermatic-kubernetes-platform/cloud/#aws "AWS") [![Azure](/images/logos/azure-logo.svg)](/products/kubermatic-kubernetes-platform/cloud/#azure "Azure") [![Google Cloud](/static/google-cloud-logo.svg)](/products/kubermatic-kubernetes-platform/cloud/#google-cloud "Google Cloud") [![Open Telekom Cloud](/images/logos/open-telekom-cloud-logo.png)](/products/kubermatic-kubernetes-platform/cloud/#open-telekom-cloud "Open Telekom Cloud") [![Alibaba Cloud](/static/alibaba-cloud-logo.svg)](/products/kubermatic-kubernetes-platform/cloud/#alibaba-cloud "Alibaba Cloud") [![Hetzner Cloud](/static/hetzner-logo.svg)](/products/kubermatic-kubernetes-platform/cloud/#hetzner-cloud "Hetzner Cloud") [![DigitalOcean](/images/logos/digitalocean-logo.svg)](/products/kubermatic-kubernetes-platform/cloud/#digitalocean "DigitalOcean") [![Equinix Metal](/static/equinix-metal-logo.svg)](/products/kubermatic-kubernetes-platform/cloud/#equinix-metal "Equinix Metal") [![KubeVirt](/static/kubevirt-horizontal-color.png)](/products/kubermatic-kubernetes-platform/cloud/#kubevirt "KubeVirt") ## Global Leaders Work With Kubermatic ![Siemens](/images/partners/8.png) ![T-Systems](/images/partners/t-systems-logo-grey.svg) ![Hilti](/images/partners/4.png) ![Allianz](/images/partners/Allianz.png) ![1&1](/images/partners/16.png) ![Bosch](/images/partners/5.png) ![Lufthansa](/images/partners/1.png) Jump to section [AWS](/products/kubermatic-kubernetes-platform/cloud/#aws) [Azure](/products/kubermatic-kubernetes-platform/cloud/#azure) [Google Cloud](/products/kubermatic-kubernetes-platform/cloud/#google-cloud) [Open Telekom Cloud](/products/kubermatic-kubernetes-platform/cloud/#open-telekom-cloud) [Alibaba Cloud](/products/kubermatic-kubernetes-platform/cloud/#alibaba-cloud) [Hetzner Cloud](/products/kubermatic-kubernetes-platform/cloud/#hetzner-cloud) [DigitalOcean](/products/kubermatic-kubernetes-platform/cloud/#digitalocean) [Equinix Metal](/products/kubermatic-kubernetes-platform/cloud/#equinix-metal) [KubeVirt](/products/kubermatic-kubernetes-platform/cloud/#kubevirt) ![AWS](/images/logos/aws-logo.svg) Kubermatic Kubernetes Platform (KKP) is an enterprise-grade Kubernetes platform that gives you deep integration and independence on AWS. Make the most out of the rich AWS universe, with advanced options like spot instances for your Kubernetes clusters to run at least cost. With KKP, developers are free to focus on their code instead of having to manage infrastructure. A single click deployment process makes it easy to scale up your clusters as demand grows over time, while monitoring tools provide visibility into cluster health and performance. And with optional 24/7 support from our team of experts, we’ll keep your business running smoothly every day so you don’t have to worry about downtime or maintenance windows! ![Azure](/images/logos/azure-logo.svg) Kubermatic Kubernetes Platform (KKP) is the best fit for global enterprises. Azure DevOps and KKP are proven in edge manufacturing environments of the highest complexity. The Azure cloud platform includes more than 200 products and cloud services, designed to support you in building new solutions. You can develop, run and manage applications - in multiple clouds, on premises or at the edge. You can use the tools and frameworks of your choice with KKP. With independence and seamless integration, it’s the perfect match for any business looking to scale up their operations without compromising quality and increased time to market through technological independence. ![Google Cloud](/static/google-cloud-logo.svg) Kubermatic Kubernetes Platform (KKP) is the most innovative open source platform for managing your workloads. It abstracts away the cloud, so you can use your data and run your apps on any cloud or in any environment, while still leveraging innovations like Google’s Machine Learning. With KKP, you get true independence from a single vendor with open-source computing that provides freedom of choice and innovation without being tied to a single vendor. ![Open Telekom Cloud](/images/logos/open-telekom-cloud-logo.png) Kubermatic Kubernetes Platform (KKP) is a Kubernetes-as-a-service platform that runs just about anywhere. We’ve been working with Open Telekom Cloud from its very beginnings and can therefore provide an unmatched level of integration between our platform, your cloud environment and your business objectives. This integration is proven by extensive use cases to reduce complexity by a factor of 20 for our shared customers. Get in touch to find out how we can help you take your digital transformation to the next level today! ![Alibaba Cloud](/static/alibaba-cloud-logo.svg) The Kubermatic Kubernetes Platform and Alibaba Cloud offer a reliable, secure, and scalable cloud computing service for enterprises. With support for containerized workloads, this solution helps simplify your development pipeline because it integrates with both continuous delivery tools as well as cloud platforms. The global reach of Alibaba Cloud provides you with high-quality compute capabilities to deploy your solutions in China, Asia or anywhere in the world. Alibaba also provides enterprise-grade security so that data is safe from unauthorized access or tampering. The Kubermatic Kubernetes Platform’s superlative level of reliability and adaptability makes it an excellent choice for organizations who want to build their next generation applications on top of leading edge technologies. ![Hetzner Cloud](/static/hetzner-logo.svg) Kubermatic Kubernetes Platform is a managed Kubernetes platform. It offers an enterprise-ready, secure and stable environment for deploying containerized applications of any size to the cloud. It offers you all of the benefits of modern application deployments in one package, with no need to worry about infrastructure or operations management. Hetzner Cloud, Europe’s largest dedicated hosting provider with over 20 years experience in running data centers, provides our customers access to high quality hardware and excellent connectivity at competitive prices, combined with trusted, reliable 24/7 service. With our integration, customers get Hetzner Cloud’s infrastructure to provide an unbeatable price / performance ratio that is optimized for scaling, regardless of whether you’re running individual applications, distributed systems, dynamic clusters, or just using the environment as a development sandbox. ![DigitalOcean](/images/logos/digitalocean-logo.svg) Kubermatic Kubernetes Platform is a cloud hosting platform built on Kubernetes that supports Digital Ocean natively. With these cloud hosting services, you can build web apps or API backends quickly and easily with a robust infrastructure. The intuitive API and developer tools are easy to use with your code, and the CI/CD add-ons let you focus more on being productive vs. dealing with server setup. Or you can simply learn the basics of managing a Kubernetes cluster by experimenting in an environment without risk to production workloads. Basically, we’ve got what developers need so they can get back to focusing on making great software! ![Equinix Metal](/static/equinix-metal-logo.svg) The Kubermatic Kubernetes Platform is a containerized, self-healing, and scalable platform for managing your applications on top of Equinix Metal. With this service you get the flexibility to deploy containers directly to bare metal nodes without any virtualization overhead. This means that users can take advantage of the full power of their hardware. Providing unrivaled performance when it counts the most. It’s also an easy way for deploying multi-container applications in production environments by combining the best features from both worlds (Kubernetes and Docker). ![KubeVirt](/static/kubevirt-horizontal-color.png) KubeVirt technology is designed to address the needs of development teams that have adopted or plan to adopt Kubernetes but have existing virtual machine-based workloads that cannot be easily containerized. More specifically, the technology provides a unified development platform on which developers can create, modify, and deploy applications that reside in both application containers and virtual machines in a common, shared environment. Kubermatic Kubernetes Platform has an integration configuring KubeVirt optimally on any cloud. --- ## Kubermatic Kubernetes Subcription for On-Prem - **URL:** https://www.kubermatic.com/products/kubermatic-kubernetes-subscription/onprem/ - **Date:** 2026-02-27 - **Description:** Bring your Kubernetes clusters into production on your chosen on-prem environment. # Kubermatic Kubernetes Subscription for On-Prem Kubermatic Kubernetes Subscription delivers the assurance that comes from years of production experience with the added benefits of control, portability, flexibility, and cost effectiveness. [Contact Us](/contact-us/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## How Kubermatic Kubernetes Subscription Covers All Your On-Prem Needs Kubermatic helps your organization create the same developer experience, reliability and sophisticated tool chain on premise as any of today’s large cloud providers. Your business can take advantage by building a lightweight Kubernetes environment that will work for them - whether they are running in-house or outside ( onstage ) their data center. ## Want to learn more now? Pick a Provider [![VMware vSphere](/static/vmware-vsphere.svg)](/products/kubermatic-kubernetes-subscription/onprem/#vmware-vsphere "VMware vSphere") [![Nutanix](/static/nutanix-logo.svg)](/products/kubermatic-kubernetes-subscription/onprem/#nutanix "Nutanix") [![OpenStack](/static/openstack-logo.svg)](/products/kubermatic-kubernetes-subscription/onprem/#openstack "OpenStack") ## Global Leaders Work With Kubermatic ![Siemens](/images/partners/8.png) ![T-Systems](/images/partners/t-systems-logo-grey.svg) ![Hilti](/images/partners/4.png) ![Allianz](/images/partners/Allianz.png) ![1&1](/images/partners/16.png) ![Bosch](/images/partners/5.png) ![Lufthansa](/images/partners/1.png) Jump to section [VMware vSphere](/products/kubermatic-kubernetes-subscription/onprem/#vmware-vsphere) [Nutanix](/products/kubermatic-kubernetes-subscription/onprem/#nutanix) [OpenStack](/products/kubermatic-kubernetes-subscription/onprem/#openstack) ![VMware vSphere](/static/vmware-vsphere.svg) Kubermatic Kubernetes Subscription is a fully managed service that provides years of experience in cluster installation, full lifecycle management and business critical support specific to your on-premise vSphere environment. Our team has the knowledge base for  hybrid environments, so that you can modernize it without disrupting legacy apps or compromising security compliance requirements. Kubermatic support specialists can help with all aspects of managing containers and Kubernetes including deployment, configuration, operations, monitoring and troubleshooting. You get the best of both worlds - virtualization software for managing traditional server workloads plus powerful management tools for containers and Kubernetes. ![Nutanix](/static/nutanix-logo.svg) Kubermatic Kubernetes Subscription is a fully managed service for Kubernetes clusters on your private Nutanix cloud. With many years of experience in cluster installation, full lifecycle management and business critical support, you get the peace of mind that comes with knowing your application and data are running securely on enterprise-grade hardware, backed by world class IT experts. Our support of your KKP and Nutanix environment will ensure high availability, as well as help you improve performance and scalability, while reducing the effort and resources needed for IT management and without sacrificing control or security. ![OpenStack](/static/openstack-logo.svg) Kubermatic Kubernetes Subscription is a fully managed service that provides extensive experience in cluster installation, full lifecycle management and business critical support of your private Openstack cloud. Managed services are provided by our cloud native team based on many years of running production clusters at scale. These include complete installation, patching, configuration management, monitoring & alerting across multi-cloud deployments for all aspects of day-to-day operational needs including infrastructure upgrades. --- ## Kubermatic Kubernetes Subscription for Edge Environments - **URL:** https://www.kubermatic.com/products/kubermatic-kubernetes-subscription/edge/ - **Date:** 2026-02-27 - **Description:** Bring your Kubernetes clusters into production on your chosen edge environment with Kubermatic Kubernetes Subscription. # Kubermatic Kubernetes Subscription for Edge Environments Adopt Kubernetes in production through validated designs for deployment and operations with 24x7 business critical management support. [Contact Us](/contact-us/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## How Kubermatic Kubernetes Subscription Covers All Your Edge Needs Kubermatic Kubernetes Subscription is a service that provides 24x7 business critical support for customers who are looking to maintain their Kubernetes clusters in production environments. Our edge solutions will help you meet the challenges of managing hundreds or thousands of distributed applications and deployment targets, as well as provide reliable connectivity when scaling improves application performance by standardizing how they’re deployed on top our platform! ## Want to learn more now? Pick a Provider [![VMware vSphere](/static/vmware-vsphere.svg)](/products/kubermatic-kubernetes-subscription/edge/#vmware-vsphere "VMware vSphere") [![Nutanix](/static/nutanix-logo.svg)](/products/kubermatic-kubernetes-subscription/edge/#nutanix "Nutanix") ## Global Leaders Work With Kubermatic ![Siemens](/images/partners/8.png) ![T-Systems](/images/partners/t-systems-logo-grey.svg) ![Hilti](/images/partners/4.png) ![Allianz](/images/partners/Allianz.png) ![1&1](/images/partners/16.png) ![Bosch](/images/partners/5.png) ![Lufthansa](/images/partners/1.png) Jump to section [VMware vSphere](/products/kubermatic-kubernetes-subscription/edge/#vmware-vsphere) [Nutanix](/products/kubermatic-kubernetes-subscription/edge/#nutanix) ![VMware vSphere](/static/vmware-vsphere.svg) With Kubermatic Kubernetes Subscription, we deliver upstream Kubernetes Support with 24x7 business critical support to help customers bring their Kubernetes clusters into production on vSphere. We provide the best of both worlds; you get upstream Kubernetes and all of the benefits of the VMware infrastructure, which enables modern Kubernetes based applications to run side by side with traditional VM based applications. With this new configuration, you can finally take advantage of all the powerful features and capabilities available in VMware infrastructure while still enjoying the best of what Kubernetes has to offer! ![Nutanix](/static/nutanix-logo.svg) Kubermatic is a fully managed service that provides years of experience in cluster installation, full lifecycle management and business critical support specifically for Nutanix. Kubermatic supports all levels of the stack from hardware to software, with a single point of contact for 24x7x365 end-to-end engineering and operations services. With their deep knowledge in both Kubernetes and Nutanix, our team can help you take advantage of this powerful combination to manage container workloads across hybrid environments at scale, while maintaining the high level of performance required by enterprise applications. --- ## Kubermatic Kubernetes Subscription for the Cloud - **URL:** https://www.kubermatic.com/products/kubermatic-kubernetes-subscription/cloud/ - **Date:** 2026-02-27 - **Description:** Bring your Kubernetes clusters into production on your chosen cloud environment with Kubermatic Kubernetes Subscription. # Kubermatic Kubernetes Subscription for the Cloud Kubermatic Kubernetes Subscription provides you with years of experience for cluster installation, full lifecycle management, and business critical support. [Contact Us](/contact-us/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## How Kubermatic Kubernetes Subscription Covers All Your Cloud Needs Kubernetes on cloud is a powerful tool that has the potential to enhance any organization’s innovation efforts. However, it lacks one important thing - deep expertise from within your company itself! In order for you and other members of staff who are not Kubernetes experts stay competitive in this ever changing market we offer our services which will take care of all environments including hybrid/multi-cloud setups. We create high end systems with enterprise grade features at an affordable price point so even small businesses can use them without breaking their budget. ## Want to learn more now? Pick a Provider [![AWS](/images/logos/aws-logo.svg)](/products/kubermatic-kubernetes-subscription/cloud/#aws "AWS") [![Azure](/images/logos/azure-logo.svg)](/products/kubermatic-kubernetes-subscription/cloud/#azure "Azure") [![Google Cloud](/static/google-cloud-logo.svg)](/products/kubermatic-kubernetes-subscription/cloud/#google-cloud "Google Cloud") [![Open Telekom Cloud](/images/logos/open-telekom-cloud-logo.png)](/products/kubermatic-kubernetes-subscription/cloud/#open-telekom-cloud "Open Telekom Cloud") [![Alibaba Cloud](/static/alibaba-cloud-logo.svg)](/products/kubermatic-kubernetes-subscription/cloud/#alibaba-cloud "Alibaba Cloud") ## Global Leaders Work With Kubermatic ![Siemens](/images/partners/8.png) ![T-Systems](/images/partners/t-systems-logo-grey.svg) ![Hilti](/images/partners/4.png) ![Allianz](/images/partners/Allianz.png) ![1&1](/images/partners/16.png) ![Bosch](/images/partners/5.png) ![Lufthansa](/images/partners/1.png) Jump to section [AWS](/products/kubermatic-kubernetes-subscription/cloud/#aws) [Azure](/products/kubermatic-kubernetes-subscription/cloud/#azure) [Google Cloud](/products/kubermatic-kubernetes-subscription/cloud/#google-cloud) [Open Telekom Cloud](/products/kubermatic-kubernetes-subscription/cloud/#open-telekom-cloud) [Alibaba Cloud](/products/kubermatic-kubernetes-subscription/cloud/#alibaba-cloud) ![AWS](/images/logos/aws-logo.svg) Kubermatic Kubernetes Subscription is a managed service that installs and manages your Kubernetes clusters on AWS. It also provides advanced options for optimization like spot instances, so you can make the most of its features while minimizing costs. With years of experience in cluster installation and full-lifecycle management, you get peace of mind with every Kubernetes request.  Tired from managing clusters? Let us do it! We offer professional services to optimize your cluster deployment on the AWS Cloud without downtime or interruption in service. No more worrying about failures or maintenance tasks, so that you can focus on developing your products and services. ![Azure](/images/logos/azure-logo.svg) Kubermatic Kubernetes Subscription on Azure is one of the best ways to get started with containers. We provide a fully managed service that provides years of experience in cluster installation, full lifecycle management and business critical support for Azure. Kubermatic Support and Azure are the best fit for global enterprises. The Azure cloud platform consists of more than 200 products and cloud services designed to support you in developing new solutions. You can develop, run, and manage applications in multiple clouds using the tools and frameworks of your choice. With Kubermatic Kubernetes Platform independence and integration remains in your control! ![Google Cloud](/static/google-cloud-logo.svg) Tired of managing your own Kubernetes cluster on the Google Cloud Platform and dealing with the headaches that come with setting up and maintaining a production quality environment? Kubermatic Support Subscription is here to help. Our fully managed service provides years of experience in cluster installation, full lifecycle management and business critical support for Google Cloud Platform. KKP and GCP both share an open source, multi- and hybrid cloud perspective, which allows you to use your data and run your apps on any cloud or in any environment. With our solutions, you get consistency between public and private clouds, so you can modernize your business and your developers can build faster in any environment. ![Open Telekom Cloud](/images/logos/open-telekom-cloud-logo.png) One of the most challenging aspects of deploying Kubernetes is getting all of the components to work together. Not every business has the expertise available in house or the budget to hire external resources. Kubermatic Kubernetes Subscription consolidates this entire process into a single service that can be deployed on Open Telekom Cloud (OTC). With years of experience in cluster installation and lifecycle management, you\`re sure to get the best results possible with minimal effort. We also provide business critical support, so you know that everything will work as expected. Our partnership with OTC ensures deep integration and customer focused services and has been proven to reduce your complexity by as much as 20 times. ![Alibaba Cloud](/static/alibaba-cloud-logo.svg) Kubermatic Kubernetes Subscription provides a robust, scalable and cost-effective way for organizations to deploy mission-critical applications on Alibaba Cloud with high availability and service level agreements. When you deploy your clusters on KKP, you can take advantage of the flexibility of Alibaba Cloud’s platform while mitigating risk, as well as saving time and money. With our managed services, we’ll do all the heavy lifting so that you can focus on running your business! --- ## Managed Custom Kubernetes for Edge Environments - **URL:** https://www.kubermatic.com/products/managed-custom-kubernetes/edge/ - **Date:** 2026-02-27 - **Description:** Our Managed Custom Kubernetes elevates your home grown Kubernetes with our operational stack to manage edge infrastructure and containers. # Managed Custom Kubernetes for Edge Environments Our Managed Custom Kubernetes elevates your home grown Kubernetes with our operational stack to make it a production grade Kubernetes-based open platform to manage edge infrastructure and containers. [Contact Sales](/contact-sales/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## How Managed Custom Kubernetes Covers All Your Edge Needs Our Managed Custom Kubernetes elevates your home grown Kubernetes with our operational stack to make it a production grade Kubernetes-based open platform to manage edge infrastructure and containers. It was designed to address the constraints and scalability challenges of edge computing, which often has resource limitations like reduced bandwidth or processing power. The product scales dynamically with your needs, so you can start small and grow as needed without downtime or data loss. You might use it to set up a single node that houses an application and then scale out when demand increases. Or you can use it to run a lot of different applications on one physical server simultaneously, without having them interfere with each other’s resources. The fully managed services gives business the comfort of onboard mission critical applications that leverages all the benefits of cloud native applications and is also backed by the best expertise in case of any eventuality. ## Want to learn more now? Pick a Provider [![VMware vSphere](/static/vmware-vsphere.svg)](/products/managed-custom-kubernetes/edge/#vmware-vsphere "VMware vSphere") [![Static BareMetal](/static/baremetal-logo.png)](/products/managed-custom-kubernetes/edge/#static-baremetal "Static BareMetal") [![Dynamic BareMetal](/static/DynamicBareMetal-Logo.PNG)](/products/managed-custom-kubernetes/edge/#dynamic-baremetal "Dynamic BareMetal") [![ARM](/static/arm-logo.svg)](/products/managed-custom-kubernetes/edge/#arm "ARM") ## Global Leaders Work With Kubermatic ![Siemens](/images/partners/8.png) ![T-Systems](/images/partners/t-systems-logo-grey.svg) ![Hilti](/images/partners/4.png) ![Allianz](/images/partners/Allianz.png) ![1&1](/images/partners/16.png) ![Bosch](/images/partners/5.png) ![Lufthansa](/images/partners/1.png) Jump to section [VMware vSphere](/products/managed-custom-kubernetes/edge/#vmware-vsphere) [Static BareMetal](/products/managed-custom-kubernetes/edge/#static-baremetal) [Dynamic BareMetal](/products/managed-custom-kubernetes/edge/#dynamic-baremetal) [ARM](/products/managed-custom-kubernetes/edge/#arm) ![VMware vSphere](/static/vmware-vsphere.svg) Managed Kubermatic Kubernetes Platform is a fully managed container-based platform that seamlessly integrates with your existing VMware vSphere installation, allowing you to leverage edge cases for your manufacturing workloads at your facility. Kubermatic\`s highly adaptable and resilient architecture is this most innovative solution with the best return on investment. With Kubermatic, optimizing product development cycles has never been easier! The fully managed services gives business the comfort of onboard mission critical applications that leverages all the benefits of cloud native applications and is also backed by the best expertise in case of any eventuality. ![Static BareMetal](/static/baremetal-logo.png) ## Static BareMetal Managed Kubermatic Kubernetes Platform is a fully managed Kubermatic cluster on bare metal,  for the simplest configuration and deployment. The integration with existing environments is seamless, as it can be deployed wherever there is network connectivity to another machine running Kubernetes. Design your infrastructure around what’s already there, not around the requisites of Kubernetes. You won’t need any management or installation tools besides the CLI and kubectl to get things up and running in minutes. Since we’re using bare metal rather than virtualization (or containers), performance benefits are gained due to increased CPU core availability and RAM capacity per node. Gone are (the days of) over provisioned nodes that can’t deliver when most needed at the Edge. The fully managed services gives business the comfort of onboard mission critical applications that leverages all the benefits of cloud native applications and is also backed by the best expertise in case of any eventuality. ![Dynamic BareMetal](/static/DynamicBareMetal-Logo.PNG) ## Dynamic BareMetal Managed Kubermatic Kubernetes Platform is a fully managed Kubernetes-based solution that allows you to orchestrate dynamic bare metal environments with all of the prerequisites for virtual machines, side by side workloads and dynamic infrastructure allocation. Your business can get on board with containers without having to buy new hardware or invest in expensive software licenses. You can make use of existing resources while leveraging the benefits of containerization at the edge. Kubermatic’s unique architecture allows for precise allocation of resources with the management plane consuming a fraction of the compute required by any other competitor. All of this is accomplished with an intuitive web interface combined with API access for mass deployment across multiple clusters. The platform provides a fully automated workflow that eliminates manual intervention and ensures high availability at all times. It also includes support for third party tools like Terraform, Ansible and Jenkins CI/CD, so that you can integrate them seamlessly. Finally, the fully managed services gives business the comfort of an onboard mission critical application that leverages all the benefits of cloud native applications and is also backed by the best expertise in case of any eventuality. ![ARM](/static/arm-logo.svg) Managed Kubermatic Kubernetes Platform is a fully managed Kubernetes service and is the only solution in the market that integrates seamlessly with any ARM infrastructure. KKP on ARM for Edge gives you all of the features and benefits of a high-end data center, in a cost efficient, power saving environment. You can leverage your existing investment by deploying KKP to your edge nodes, where it will continue to have full access to all enterprise level security, scalability and reliability. Additionally, because our platform was built from scratch using microservices architecture, you get an easy way to deploy software updates without downtime or service interruptions. Finally, the fully managed services gives business the comfort of an onboard mission critical application that leverages all the benefits of cloud native applications and is also backed by the best expertise in case of any eventuality. --- ## Managed Custom Kubernetes for On-Prem - **URL:** https://www.kubermatic.com/products/managed-custom-kubernetes/onprem/ - **Date:** 2026-02-27 - **Description:** A fully managed Container Platform that is specifically built for on premise infrastructure and container needs. # Managed Custom Kubernetes for On-Prem Our Managed Custom Kubernetes combines your home grown Kubernetes with our operation stack to elevate it to a production grade platform. [Contact Sales](/contact-sales/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## How Managed Custom Kubernetes Covers All Your On-Prem Needs Our Managed Custom Kubernetes combines your home grown Kubernetes with our operation stack to elevate it to a production grade platform. The result is a fully managed Container Platform that is specifically built for on premise infrastructure and container needs. It handles hyperconverged, bare metal, and any virtualization, and comes with unrivaled adaptability, resilience and ROI. The platform was created to provide enterprises with the best solution for their container management needs at an affordable price, without compromising quality or performance. Finally, the fully managed services gives business the comfort of an onboard mission critical application that leverages all the benefits of cloud native applications and is also backed by the best expertise in case of any eventuality. ## Want to learn more now? Pick a Provider [![VMware vSphere](/static/vmware-vsphere.svg)](/products/managed-custom-kubernetes/onprem/#vmware-vsphere "VMware vSphere") [![Nutanix](/static/nutanix-logo.svg)](/products/managed-custom-kubernetes/onprem/#nutanix "Nutanix") [![OpenStack](/static/openstack-logo.svg)](/products/managed-custom-kubernetes/onprem/#openstack "OpenStack") [![Static BareMetal](/static/baremetal-logo.png)](/products/managed-custom-kubernetes/onprem/#static-baremetal "Static BareMetal") [![Dynamic BareMetal](/static/DynamicBareMetal-Logo.PNG)](/products/managed-custom-kubernetes/onprem/#dynamic-baremetal "Dynamic BareMetal") ## Global Leaders Work With Kubermatic ![Siemens](/images/partners/8.png) ![T-Systems](/images/partners/t-systems-logo-grey.svg) ![Hilti](/images/partners/4.png) ![Allianz](/images/partners/Allianz.png) ![1&1](/images/partners/16.png) ![Bosch](/images/partners/5.png) ![Lufthansa](/images/partners/1.png) Jump to section [VMware vSphere](/products/managed-custom-kubernetes/onprem/#vmware-vsphere) [Nutanix](/products/managed-custom-kubernetes/onprem/#nutanix) [OpenStack](/products/managed-custom-kubernetes/onprem/#openstack) [Static BareMetal](/products/managed-custom-kubernetes/onprem/#static-baremetal) [Dynamic BareMetal](/products/managed-custom-kubernetes/onprem/#dynamic-baremetal) ![VMware vSphere](/static/vmware-vsphere.svg) Our Managed Custom Kubernetes blends your home grown Kubernetes with our operation stack to make it a production grade platform. With the Kubernetes Platform and VMware vSphere you get the best of both worlds - virtualization software for managing traditional server workloads together with powerful management tools for containers and Kubernetes. This hybrid approach gives you everything you need to modernize your IT environment without disrupting legacy apps or compromising security compliance requirements. Finally, the fully managed services gives business the comfort of an onboard mission critical application that leverages all the benefits of cloud native applications and is also backed by the best expertise in case of any eventuality. ![Nutanix](/static/nutanix-logo.svg) Nutanix and Kubermatic Platform are a match made in heaven for on premise workloads. The hyperconverged infrastructure with state of the art software aligns perfectly with our Kubernetes Platform to manage container workloads in any hybrid scenario. Our Managed Custom Kubernetes  your home grown Kubernetes with our operation stack to take it to a production grade Kubernetes platform on Nutanix where, you can deploy virtualized or container based applications at scale, without sacrificing performance, availability or security – all from a single platform that integrates compute storage and networking as well as the latest open source technology. Finally, the fully managed services gives business the comfort of an onboard mission critical application that leverages all the benefits of cloud native applications and is also backed by the best expertise in case of any eventuality. ![OpenStack](/static/openstack-logo.svg) Our Managed Custom Kubernetes merges your home grown Kubernetes with our operation stack to take it to a production grade Kubermatic platform, to manage large pools of compute, storage and networking resources on Openstack. You can use the same set of APIs or dashboard to manage your containers and your traditional virtual machines, all from a single pane of glass. Product combinations like this are perfect when you need more control over how your infrastructure is deployed, when it gets patched and what tools are being used. With Kubermatic, our users have access to everything they need in one place - whether that’s orchestration across multiple hosts or just monitoring CPU usage within a single machine. Finally, the fully managed services gives business the comfort of an onboard mission critical application that leverages all the benefits of cloud native applications and is also backed by the best expertise in case of any eventuality. ![Static BareMetal](/static/baremetal-logo.png) ## Static BareMetal Our Managed Custom Kubernetes takes your home grown Kubernetes and combines it with our operation stack and elevates it to a production grade platform, that serves as a native, enterprise-grade solution and unifies the management of on-premises and public cloud resources. The fully managed version of the platform combines the power of Kubernetes with unique features for managing bare metal environments to provide you with an unmatched price-to-performance ratio. No additional technology is needed to run supercomputing farms via Kubernetes. Finally, the fully managed services gives business the comfort of an onboard mission critical application that leverages all the benefits of cloud native applications and is also backed by the best expertise in case of any eventuality. ![Dynamic BareMetal](/static/DynamicBareMetal-Logo.PNG) ## Dynamic BareMetal Our Managed Custom Kubernetes marries your home grown Kubernetes with our operation stack to transform it to a production grade platform, and provide a fully managed Kubermatic based solution. This allows you to orchestrate dynamic bare metal environments with all of the prerequisites for virtual machines, side by side workloads and dynamic infrastructure allocation. Your business is onboarded with containers without the need for expensive new hardware or investing in costly software licenses. You can make the best use of existing resources while leveraging the benefits of containerization. All of this is done with an intuitive web interface and API access for mass deployment across multiple clusters. Finally, the fully managed services gives business the comfort of an onboard mission critical application that leverages all the benefits of cloud native applications and is also backed by the best expertise in case of any eventuality. --- ## Managed Custom Kubernetes for the Cloud - **URL:** https://www.kubermatic.com/products/managed-custom-kubernetes/cloud/ - **Date:** 2026-02-27 - **Description:** Our management tools stack is built for container management in any cloud and for any need. # Managed Custom Kubernetes for the Cloud Managed Kubermatic Platform is a fully managed version of Kubermatic and has all of the features you need to deploy, manage, and scale containers in any environment, from a single laptop to the largest cloud providers. [Contact Sales](/contact-sales/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## How Managed Custom Kubernetes Covers All Your Cloud Needs Our Managed Custom Kubernetes elevates your home grown Kubernetes to a production grade platform. Our management tools stack is built for container management in any cloud and for any need. Managed Kubermatic Platform is a fully managed version of Kubermatic and has all of the features you need to deploy, manage, and scale containers in any environment, from a single laptop to the largest cloud providers. Finally, the fully managed services gives business the comfort of an onboard mission critical application that leverages all the benefits of cloud native applications and is also backed by the best expertise in case of any eventuality. ## Want to learn more now? Pick a Provider [![AWS](/images/logos/aws-logo.svg)](/products/managed-custom-kubernetes/cloud/#aws "AWS") [![Azure](/images/logos/azure-logo.svg)](/products/managed-custom-kubernetes/cloud/#azure "Azure") [![Google Cloud](/static/google-cloud-logo.svg)](/products/managed-custom-kubernetes/cloud/#google-cloud "Google Cloud") [![Open Telekom Cloud](/images/logos/open-telekom-cloud-logo.png)](/products/managed-custom-kubernetes/cloud/#open-telekom-cloud "Open Telekom Cloud") [![Alibaba Cloud](/static/alibaba-cloud-logo.svg)](/products/managed-custom-kubernetes/cloud/#alibaba-cloud "Alibaba Cloud") [![Hetzner](/static/hetzner-logo.svg)](/products/managed-custom-kubernetes/cloud/#hetzner "Hetzner") [![DigitalOcean](/images/logos/digitalocean-logo.svg)](/products/managed-custom-kubernetes/cloud/#digitalocean "DigitalOcean") [![Equinix Metal](/static/equinix-metal-logo.svg)](/products/managed-custom-kubernetes/cloud/#equinix-metal "Equinix Metal") ## Global Leaders Work With Kubermatic ![Siemens](/images/partners/8.png) ![T-Systems](/images/partners/t-systems-logo-grey.svg) ![Hilti](/images/partners/4.png) ![Allianz](/images/partners/Allianz.png) ![1&1](/images/partners/16.png) ![Bosch](/images/partners/5.png) ![Lufthansa](/images/partners/1.png) Jump to section [AWS](/products/managed-custom-kubernetes/cloud/#aws) [Azure](/products/managed-custom-kubernetes/cloud/#azure) [Google Cloud](/products/managed-custom-kubernetes/cloud/#google-cloud) [Open Telekom Cloud](/products/managed-custom-kubernetes/cloud/#open-telekom-cloud) [Alibaba Cloud](/products/managed-custom-kubernetes/cloud/#alibaba-cloud) [Hetzner](/products/managed-custom-kubernetes/cloud/#hetzner) [DigitalOcean](/products/managed-custom-kubernetes/cloud/#digitalocean) [Equinix Metal](/products/managed-custom-kubernetes/cloud/#equinix-metal) ![AWS](/images/logos/aws-logo.svg) Our Managed Custom Kubernetes joins your home grown Kubernetes with our operation stack to take it to a production grade platform, to give you extensive integration and full independence on AWS. You can take advantage of the rich AWS universe, with advanced options like spot instances for your Kubernetes clusters so they run at the lowest cost. With the new platform, developers are free to focus on their code instead of managing infrastructure. A single click deployment process makes it easy to scale up your clusters as demand grows over time, while monitoring tools provide visibility into cluster health and performance. And with 24/7 support from our team of experts, we’ll keep your business running smoothly so you don’t have to worry about downtime or maintenance windows! Finally, the fully managed services gives business the comfort of an onboard mission critical application that leverages all the benefits of cloud native applications and is also backed by the best expertise in case of any eventuality. ![Azure](/images/logos/azure-logo.svg) Our Managed Custom Kubernetes with our operation stack elevates your home grown Kubernetes to a production grade platform. A fully managed Kubernetes Platform is the best fit for global enterprises. Azure DevOps and Kubernetes Platform on Azure are the de facto solution for high complexity manufacturing environments at the edge. The Azure cloud platform includes more than 200 products and cloud services, designed to support you in developing new solutions. You can develop, run and manage applications - in multiple clouds, on-premises or at the edge. You can complement your tools and frameworks of choice with our tool set. With independence and integration intact, it’s a perfect match for any business looking to scale up their operations without compromising quality or slowing down time to market! Finally, the fully managed services gives business the comfort of an onboard mission critical application that leverages all the benefits of cloud native applications and is also backed by the best expertise in case of any eventuality. ![Google Cloud](/static/google-cloud-logo.svg) Our Managed Custom Kubernetes elevates your home grown Kubernetes to a production grade platform. The Kubernetes Platform complemented by our operations stack and best practices is the most innovative open source platform for managing your workloads. It abstracts away any cloud provider dependence, so you can use your data and run your apps on any cloud or in any environment, while still leveraging innovations like Google’s machine learning. You get true independence from any single vendor and open-source computing that provides freedom of choice and innovation without lock-in. Finally, the fully managed services gives business the comfort of an onboard mission critical application that leverages all the benefits of cloud native applications and is also backed by the best expertise in case of any eventuality. ![Open Telekom Cloud](/images/logos/open-telekom-cloud-logo.png) Our Managed Custom Kubernetes elevates your home grown Kubernetes with our operations stack to take it to a production grade platform that runs anywhere as a fully managed version of this Kubermatic. We have been working with Open Telekom Cloud since Day 1 and now offer you an unmatched level of integration between our platform, your cloud environment and your business objectives. Historically, use cases of this integration have proven to reduce complexity of our joint clients by a factor of 20. Get in touch to find out how we can help you take your digital transformation to the next level today! Finally, the fully managed services gives business the comfort of an onboard mission critical application that leverages all the benefits of cloud native applications and is also backed by the best expertise in case of any eventuality. ![Alibaba Cloud](/static/alibaba-cloud-logo.svg) Our Managed Custom Kubernetes elevates your home grown Kubernetes with our operations stack to take it to a production grade Kubernetes platform on Alibaba Cloud. This combination offers a reliable, secure, and scalable cloud computing service for enterprises. With support for Kubernetes containerized workloads, this solution helps simplify your development pipeline because it integrates with continuous delivery tools and cloud platforms alike. The global reach of Alibaba Cloud provides high-quality compute capabilities to deploy your solutions in China, Asia or anywhere in the world. You also get enterprise-grade security so that data is safe from unauthorized access or tampering. The level of reliability and adaptability makes the enhanced Kubernetes Platform an excellent choice for organizations who want to build their next generation applications on top of leading edge technologies. Finally, the fully managed services gives business the comfort of an onboard mission critical application that leverages all the benefits of cloud native applications and is also backed by the best expertise in case of any eventuality. ![Hetzner](/static/hetzner-logo.svg) Our Managed Custom Kubernetes elevates your home grown Kubernetes with our operations stack to take it to a production grade platform. The Kubernetes Platform offers an enterprise-ready, secure and stable environment for deploying containerized applications of any size to the cloud. We offer you all of the benefits of modern application deployment in one package, without the need to worry about infrastructure or operations management. Hetzner Cloud, Europe’s largest dedicated hosting provider with over 20 years experience in running data centers, provides our customers access to high quality hardware and excellent connectivity. Our integration, together with Hetzner Cloud’s infrastructure provides excellent performance, is competitively priced, and optimized for scaling. The benefits are there in every area, whether you’re running individual applications, distributed systems, dynamic clusters, or just using the environment as a development sandbox. Finally, the fully managed services gives business the comfort of an onboard mission critical application that leverages all the benefits of cloud native applications and is also backed by the best expertise in case of any eventuality. ![DigitalOcean](/images/logos/digitalocean-logo.svg) Our Managed Custom Kubernetes with our operations tool stack elevates your home grown Kubernetes to a production grade platform, and supports DigitalOcean natively.  With a basic cloud hosting service, you can build web apps or API backends quickly and easily with a robust infrastructure. The intuitive API and developer tools make it easy to work with your code while the CI/CD add-ons let you focus more on being productive and less on dealing with server setup. Or simply learn the basics of managing a Kubernetes cluster by experimenting without any risk to production workloads. We’ve got what developers need to get back to focusing on making great software! Finally, the fully managed services gives business the comfort of an onboard mission critical application that leverages all the benefits of cloud native applications and is also backed by the best expertise in case of any eventuality. ![Equinix Metal](/static/equinix-metal-logo.svg) Our Managed Custom Kubernetes elevates your home grown Kubernetes to a production grade platform. This is a fully managed Kubermatic Platform, containerized, self-healing, and scalable,to run all of your applications on Equinix Metal. With this service you get the flexibility to deploy containers directly to bare metal nodes without any virtualization overhead. Users can take advantage of the full potential of their hardware without having to worry about wasting the resources or energy of traditional virtual machines. It also provides an easy way to deploy multi-container applications in production environments by combining the best features from both worlds (Kubernetes and Docker). Finally, the fully managed services gives business the comfort of an onboard mission critical application that leverages all the benefits of cloud native applications and is also backed by the best expertise in case of any eventuality. --- ## Managed Kubermatic KubeOne for Edge Environments - **URL:** https://www.kubermatic.com/products/managed-kubermatic-kubeone/edge/ - **Date:** 2026-03-17 - **Description:** The future of edge and IoT environments is here. With one tool, you can automate all operations across every platform - no more navigating multiple platforms. # Managed Kubermatic KubeOne for Edge Environments With Managed Kubermatic KubeOne, we take the headache out of managing your Kubernetes cluster. With full lifecycle management for edge or in IoT deployments, you’ll never have to worry about another tedious task again! [Contact Us](/contact-us/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## How Managed KubeOne Covers All Your Edge Needs Managed KubeOne takes your Kubernetes clusters to the next level, creating and managing highly available environments on every edge computing location. This means you can optimize bandwidth usage for users by adapting their experience based off of where they are located in terms or availability connectivity etc., while also improving responsiveness with less downtime when things go wrong because we’ve got our eye out right there! ## Want to learn more now? Pick a Provider [![VMware vSphere](/static/vmware-vsphere.svg)](/products/managed-kubermatic-kubeone/edge/#vmware-vsphere "VMware vSphere") [![Static BareMetal](/static/baremetal-logo.png)](/products/managed-kubermatic-kubeone/edge/#static-baremetal "Static BareMetal") [![ARM](/static/arm-logo.svg)](/products/managed-kubermatic-kubeone/edge/#arm "ARM") ## Global Leaders Work With Kubermatic ![Siemens](/images/partners/8.png) ![T-Systems](/images/partners/t-systems-logo-grey.svg) ![Hilti](/images/partners/4.png) ![Allianz](/images/partners/Allianz.png) ![1&1](/images/partners/16.png) ![Bosch](/images/partners/5.png) ![Lufthansa](/images/partners/1.png) Jump to section [VMware vSphere](/products/managed-kubermatic-kubeone/edge/#vmware-vsphere) [Static BareMetal](/products/managed-kubermatic-kubeone/edge/#static-baremetal) [ARM](/products/managed-kubermatic-kubeone/edge/#arm) ![VMware vSphere](/static/vmware-vsphere.svg) Managed KubeOne empowers you to securely create and operate highly available Kubernetes clusters on VMware vSphere on the edge. It’s a perfect fit for manufacturing use cases, where customers leverage existing environments and upgrade them to cloud native infrastructure. The KubeOne for Edge Environments on vSphere Edge service is designed with operations in mind – it has been conceptualized from the ground up to be easy-to-manage and scale as necessary. Customers can easily deploy clusters of any size that will grow or shrink automatically as needed. And because we use cloud native standards you don’t have to worry about vendor lock-in—you can always move your workloads elsewhere if needed! With Kubermatic’s managed services, you leverage all the benefits that Kubernetes and cloud native have to offer while deploying and managing your business-critical applications with ease and confidence. ![Static BareMetal](/static/baremetal-logo.png) ## Static BareMetal Managed KubeOne allows you to deploy highly available bare metal Kubernetes clusters on the edge. KubeOne leverages existing environments so that you can easily integrate your current technology stack and upgrade it to a cloud native infrastructure. This enables rapid, cost-effective adoption of enterprise-grade cloud technologies without disruption or downtime. Edge computing has become an essential part of manufacturing and other industries where data needs to be processed in real time. KubeOne gives your company access to those resources right from your factory floor or field office without the need for costly hardware acquisition, installation, deployment or management by IT staff. The result is reduced costs and increased productivity – making the future possible today! Kubermatic’s  managed services give you the comfort of deploying and running your business-critical applications confidently while leveraging all the best-in-breed tooling the cloud native landscape has to offer. ![ARM](/static/arm-logo.svg) Managed KubeOne is a container-native solution to safely deploy and run mission-critical workloads on the edge. KubeOne uses ARM architecture so it can be deployed on any device from an edge router to a Raspberry Pi at the IoT gateway. In addition, KubeOne has been designed with an API-first approach in mind so you can easily integrate your existing infrastructure without having to build something new or replace legacy systems that may not have cloud native capabilities. Our customers range from manufacturers who want the best way to manage their IoT devices to retailers who need a scalable content delivery network, and many more! With Kubermatic’s managed services, our experts make sure your mission-critical applications will be up and running at all times while you advance your infrastructure with all the best-in-breed technologies the cloud native landscape has to offer. --- ## Managed Kubermatic KubeOne for On-Prem - **URL:** https://www.kubermatic.com/products/managed-kubermatic-kubeone/onprem/ - **Date:** 2026-02-27 - **Description:** Our open-source cluster lifecycle tool has been designed to simplify the process of deploying an upstream Highly Available Kubernetes infrastructure on your own datacenter. # Managed Kubermatic KubeOne for On-Prem A container-native solution to safely deploy and run mission-critical workloads in your own datacenter. [Contact Sales](/contact-sales/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## How Managed KubeOne Covers All Your On-Prem Needs Kubernetes is the answer to your needs when it comes to managing Kubernets on-prem. With Managed KubeOne, you can focus more on developing and don’t need to worry about maintaining an infrastructure that will always be up-to-date with latest innovations in software engineering practices! ## Want to learn more now? Pick a Provider [![VMware vSphere](/static/vmware-vsphere.svg)](/products/managed-kubermatic-kubeone/onprem/#vmware-vsphere "VMware vSphere") [![OpenStack](/static/openstack-logo.svg)](/products/managed-kubermatic-kubeone/onprem/#openstack "OpenStack") [![Static BareMetal](/static/baremetal-logo.png)](/products/managed-kubermatic-kubeone/onprem/#static-baremetal "Static BareMetal") ## Global Leaders Work With Kubermatic ![Siemens](/images/partners/8.png) ![T-Systems](/images/partners/t-systems-logo-grey.svg) ![Hilti](/images/partners/4.png) ![Allianz](/images/partners/Allianz.png) ![1&1](/images/partners/16.png) ![Bosch](/images/partners/5.png) ![Lufthansa](/images/partners/1.png) Jump to section [VMware vSphere](/products/managed-kubermatic-kubeone/onprem/#vmware-vsphere) [OpenStack](/products/managed-kubermatic-kubeone/onprem/#openstack) [Static BareMetal](/products/managed-kubermatic-kubeone/onprem/#static-baremetal) ![VMware vSphere](/static/vmware-vsphere.svg) Managed KubeOne enables you to deploy highly available, fault-tolerant Kubernetes clusters on your VMware vSphere infrastructure. It’s the ideal solution for businesses that seek to upgrade to cloud native technologies but want to integrate their existing technology stack. Thanks to its API-first design, KubeOne makes this process seamless, by providing automated deployment, configuration and scaling for any environment. With our fully managed service you deploy and run your mission-critical services with ease and confidence while leveraging the benefits of all the best-in-class solutions the cloud native landscape offers. ![OpenStack](/static/openstack-logo.svg) Managed KubeOne is the most reliable and scalable solution to deploy and run highly available, fault tolerant Kubernetes clusters on OpenStack on-prem environments. KubeOne is the only on-prem OpenStack distribution that can be deployed as a single node, but also scales to any size. KubeOne delivers high availability Kubernetes clusters for production environments and makes it easy to upgrade your current environment to state-of-the-art cloud native infrastructure – an ideal match for all companies that seek to leverage best-in-class open source tooling while our experts make sure your business-critical applications are up and running at all times. ![Static BareMetal](/static/baremetal-logo.png) ## Static BareMetal Managed KubeOne offers you with the most reliable solution to deploy and run highly available Kubernetes clusters on your static bare metal on-prem environment. If you\`re running an old operating system or using outdated hardware, we can easily upgrade that old infrastructure to a state-of-the-art cloud native infrastructure that works seamlessly with the rest of your stack and won’t require any changes to how you work or update systems. At the same time, KubeOne’s API-first design gives you full flexibility to select best-in-breed solutions from the entire cloud native landscape. With our fully managed services, you can rely that your critical workloads are up and running and backed by the best expertise in case of any eventuality. --- ## Managed Kubermatic KubeOne for the Cloud - **URL:** https://www.kubermatic.com/products/managed-kubermatic-kubeone/cloud/ - **Date:** 2026-03-17 - **Description:** Pilot your Kubernetes project with our cluster lifecycle management tool by easily deploying your cluster in minutes in the cloud on your chosen provider. # Managed Kubermatic KubeOne for the Cloud Easily deploy your Kubernetes cluster in the cloud on your chosen provider. [Contact Sales](/contact-sales/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## How Managed KubeOne Covers All Your Cloud Needs Managed KuberOne is a fully-managed version of KubeOne that makes it easy to deploy and manage clusters on all your cloud environments.Automatically installing, provisioning upgrades, repairing uninstalling - you don’t have to worry about any part! With outOfTheBox support for major providers like AWS Microsoft Azure Google Cloud Hetzner OpenStack or even VMware vSphere this tool covers every base when managing your Kubernetes cluster. You can now enjoy the benefits of managing your mission-critical applications without worry, as we got you covered with our fully managed services. Flexibility and expertise is at hand when it comes to integrating best-in class open source solutions while being sure that you are backed by an organization who knows what needs to be done in case anything goes wrong! ## Want to learn more now? Pick a Provider [![AWS](/images/logos/aws-logo.svg)](/products/managed-kubermatic-kubeone/cloud/#aws "AWS") [![Azure](/images/logos/azure-logo.svg)](/products/managed-kubermatic-kubeone/cloud/#azure "Azure") [![Google Cloud](/static/google-cloud-logo.svg)](/products/managed-kubermatic-kubeone/cloud/#google-cloud "Google Cloud") [![Open Telekom Cloud](/images/logos/open-telekom-cloud-logo.png)](/products/managed-kubermatic-kubeone/cloud/#open-telekom-cloud "Open Telekom Cloud") [![Alibaba Cloud](/static/alibaba-cloud-logo.svg)](/products/managed-kubermatic-kubeone/cloud/#alibaba-cloud "Alibaba Cloud") [![Hetzner Cloud](/static/hetzner-logo.svg)](/products/managed-kubermatic-kubeone/cloud/#hetzner-cloud "Hetzner Cloud") [![DigitalOcean](/images/logos/digitalocean-logo.svg)](/products/managed-kubermatic-kubeone/cloud/#digitalocean "DigitalOcean") [![Equinix Metal](/static/equinix-metal-logo.svg)](/products/managed-kubermatic-kubeone/cloud/#equinix-metal "Equinix Metal") ## Global Leaders Work With Kubermatic ![Siemens](/images/partners/8.png) ![T-Systems](/images/partners/t-systems-logo-grey.svg) ![Hilti](/images/partners/4.png) ![Allianz](/images/partners/Allianz.png) ![1&1](/images/partners/16.png) ![Bosch](/images/partners/5.png) ![Lufthansa](/images/partners/1.png) Jump to section [AWS](/products/managed-kubermatic-kubeone/cloud/#aws) [Azure](/products/managed-kubermatic-kubeone/cloud/#azure) [Google Cloud](/products/managed-kubermatic-kubeone/cloud/#google-cloud) [Open Telekom Cloud](/products/managed-kubermatic-kubeone/cloud/#open-telekom-cloud) [Alibaba Cloud](/products/managed-kubermatic-kubeone/cloud/#alibaba-cloud) [Hetzner Cloud](/products/managed-kubermatic-kubeone/cloud/#hetzner-cloud) [DigitalOcean](/products/managed-kubermatic-kubeone/cloud/#digitalocean) [Equinix Metal](/products/managed-kubermatic-kubeone/cloud/#equinix-metal) ![AWS](/images/logos/aws-logo.svg) Managed KubeOne is a fully managed solution for deploying and managing highly available clusters on AWS cloud. Advanced features like AWS spot instances support help you achieve the best possible cost-efficiency for running your cluster in production. KubeOne is a full-stack solution that includes all of the components you need to deploy highly available clusters – from installation of kubeadm through monitoring, alerting and logging tools. With Kubermatic’s managed services you are backed by the best expertise at all times and don’t have to worry about anything except getting things done! ![Azure](/images/logos/azure-logo.svg) Have you ever wanted to deploy a highly available Kubernetes cluster on Azure? Managed KubeOne on AWS is the solution for you. KubeOne is a full-stack, open source solution for deploying and managing highly available clusters on any infrastructure. Designed from the beginning to work perfectly alongside all of Azure\`s products and services, you can create an environment in which your applications run smoothly and efficiently. KubeOne comes with powerful features like remote management, monitoring and troubleshooting so that your deployment will be seamless. Because it won’t lock you into any proprietary hardware or software solutions, KubeOne is perfect for businesses that want to leverage the benefits of cloud computing without sacrificing their flexibility to integrate the best solutions from everywhere. With Kubermatic’s managed services you are backed by the best cloud native expertise and can run your critical applications with confidence. ![Google Cloud](/static/google-cloud-logo.svg) Managed KubeOne is a fully managed solution for deploying and managing highly available Kubernetes clusters on Google Cloud Platform. KubeOne comes with an easy to use interface that leverages existing environments and upgrades them to cloud native. KubeOne works in perfect conjunction with Google Cloud Platform, so you can fully realize the strengths of both platforms. With KubeOne you spin up a cluster in minutes, scale it up or down as needed, and replace your legacy infrastructure with one that scales cost-effectively while retaining performance. The combination of KubeOne’s ease of use and integration with Google Cloud Platform provides consistency between public and private clouds, enabling businesses to modernize their infrastructure while developers build faster in any environment. ![Open Telekom Cloud](/images/logos/open-telekom-cloud-logo.png) Managed KubeOne is your best bet for deploying and operating highly available Kubernetes clusters on Open Telekom Cloud. The CLI-interface is easy to use and leverages any cloud environment, so you can quickly migrate to a Kubernetes-powered infrastructure. KubeOne has a strong partnership with OTC, with several ongoing use cases that have proven to reduce complexity by 20 times. This helps you deliver the best possible service to your customers and cut costs by half or better! ![Alibaba Cloud](/static/alibaba-cloud-logo.svg) Managed KubeOne is an easy-to-use, full-stack solution for deploying and operating highly available clusters on Alibaba Cloud. The KubeOne cluster lifecycle management tool is open source, so it’s free to download and use. KubeOne takes advantage of the inherent flexibility of the Alibaba Cloud platform and provides a cost effective way to deploy mission critical applications in a highly scalable way. Deploying your clusters with KubeOne helps you mitigate risk, saves you time and money, and let’s you focus on what matters most - running your business! ![Hetzner Cloud](/static/hetzner-logo.svg) Managed KubeOne is a full-stack, open source solution for deploying Kubernetes clusters on Hetzner Cloud. KubeOne delivers highly available clusters for production and makes it easy to upgrade your current environment to a Kubernetes-powered infrastructure. Together, KubeOne and Hetzner Cloud provide excellent performance and scalability with an unmatched price-to-performance ratio. You can use KubeOne to deploy large scale systems like Elasticsearch, Kafka or Cassandra on our cloud infrastructure. Or you can use it for an individual application, hosted on the Hetzner Cloud with settings that are customized to your requirements. There are several deployment options to suit your particular needs! ![DigitalOcean](/images/logos/digitalocean-logo.svg) Managed KubeOne is a full-stack, open source solution for deploying Kubernetes clusters on Digital Ocean. By leveraging the KubeOne API with best-in-class DevOps and CI/CD tooling, you can easily deploy container-based applications into production environments and speed up development. The intuitive API makes it easy for developers to build web apps or API backends on a robust infrastructure. With Managed KubeOne, we deliver a scalable solution for making sure your clusters are always online and able to handle traffic spikes, without downtime due to upgrades or maintenance windows. ![Equinix Metal](/static/equinix-metal-logo.svg) Managed KubeOne is the easiest and most secure way to deploy highly available Kubernetes clusters on Equinix Metal. Together, Equinix Metal and KubeOne provide a powerful and feature-rich solution for running containerized workloads at scale. With KubeOne, you can effortlessly manage your services across multiple locations – all while taking advantage of the unmatched global reach and connectivity ecosystem of Equinix Metal. --- ## Understanding Containers - **URL:** https://www.kubermatic.com/topics/understanding-containers/ - **Date:** 2024-07-15 - **Description:** Learn more about containers, how they are different to virtual machines and container security with Kubernetes. # Understanding Containers ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Jump To Section [Understanding Containers](#understanding-containers) [Container Orchestration](#container-orchestration) [Container Benefits](#container-benefits) [Container Security With Kubernetes](#container-security-with-kubernetes) [What Are Container Platforms?](#what-are-container-platforms) [Why Use Container Platforms?](#why-use-container-platforms) [How to Use Container Platforms?](#how-to-use-container-platforms) [Container Platform Examples](#container-platform-examples) ## Understanding Containers In today’s competitive landscape, companies are in a race to build more agile cloud native systems that support dynamic deployment models for their applications and services. Containers provide an ideal building block for this new model because they are lightweight, portable across platforms, and easily scalable. This guide gives you insight into the world of containers and discusses the many features and benefits of the Kubernetes container orchestration platform. ## **What Are Containers?** A container is a way of packaging software, such as an application or service, so it can be stored or run on a computer. Containers use operating system virtualization similar to hardware virtualization. However, containers rely on the kernel features of the host operating system rather than requiring hardware support. Containers allow developers to package their applications in a way that makes them portable across different environments. For example, a Java developer may develop their application on CentOS 6 (an older OS), while the software runs on CentOS 7 (a newer OS). The same developer could also use containers to ship their application to a different environment. One way to think about a container is as a portable, self-sufficient, executable package that includes all the necessary dependencies, including code, runtime, system tools, and libraries. They can be moved from one computing environment to another (such as from development to test or production systems) without concern for conflicts with other software versions or incompatibilities with shared libraries. **Containers vs. VMs** Virtual machines (VMs) are a technology that enables software, such as an operating system, to run on top of another operating system. Virtual machines are also known as guest operating systems. VMs are software emulations of computers that allow multiple operating systems to run on the same physical machine. In contrast to containers, VMs have independent OS kernels, file systems, and network interfaces. The VM’s files reside on a virtual hard drive stored in a file on the physical machine’s hard drive. They also have their own IP addresses, making them independent from the host machines. Containers, on the other hand, share the host machine’s kernel. They also share the host machine’s network interface and file system. The main difference between containers and VMs is that containers are a way to package an application with its dependencies into a standardized unit for software development, deployment, and delivery. Containers have their own file system, memory space, and isolated networking environment that only allows communication from within the container. [See More](/blog/getting-started-with-containers/) ## Container Orchestration An application could consist of a few containers to hundreds of containers. Rather than managing containers manually, developers use orchestration to handle all tasks associated with running containers. Orchestration handles the following: - Provisioning and deploying containers - Configuring containers - Scheduling - Resource allocation - Managing container availability - Load balancing - Routing traffic to containers - Security There are several solutions to orchestrate containers but over the past few years, Kubernetes has become the de facto standard to deploy and orchestrate containerized applications. Kubernetes was originally developed at Google and open sourced in 2014. Building on Google’s long-standing experience with running containerized workloads at scale, it makes everything related to deploying and managing containers easier and more secure. ### Kubernetes Orchestration Architecture A Kubernetes cluster consists of one or more nodes that can run multiple containers which are systematically organized into so-called pods.  **Nodes** Nodes are virtual machines that communicate with each other using the Kubernetes control plane. The Kubernetes control plane uses network and storage resources managed by the Kubernetes API server and scheduler to ensure that pods are scheduled on nodes with sufficient resources and that pods are placed on nodes with available capacity. **Pods (What Is a Kubernetes Pod vs. a Container)** A Kubernetes pod is a logical group of one or more containers that share the same network, storage, and other resources. It contains the systematic needs of the application it serves. Pods are the smallest, most fundamental object in Kubernetes. ## Container Benefits Containers have become a valuable tool for creating lightweight software that can be deployed and scaled quickly. Containers offer additional benefits such as: **Reduce complexity** – Instead of setting up an operating system instance for each application, you can use containers to set up a single OS instance with multiple applications running on top of it. This reduces complexity by reducing the number of operating systems needed, which saves on hardware costs and reduces management overhead as fewer instances need to be set up and maintained. **Reduce costs** – The fewer instances required, the lower the costs. Containers are also very efficient, allowing you to run more applications per server than traditional virtual machines. A single OS instance can support multiple containers without additional overheads. In addition, containers are faster than virtual machines because they do not require an entire guest operating system to be run and managed for each application. **Make use of existing infrastructure** – Using containers does not require any changes to existing infrastructure as it uses standard hardware and software configurations for operating systems and hypervisors. This means that no additional hardware is required. **Maintain security –** Containers are less complex than virtual machines and are therefore more secure. Because they share one OS instance, there is no need to run multiple operating systems on the same hardware, which reduces the number of potential attack points. In addition, because containers do not have a full operating system, there is no need to patch a guest OS – patches only need to be applied at the kernel level. This also makes containers simpler and more agile than virtual machines as there is no need for image consistency between different versions of an OS. **Reduce costs** – Using containers can reduce IT costs by allowing you to consolidate multiple applications onto fewer servers and manage them centrally from an enterprise container platform. You can also make use of existing infrastructure such as storage and networks without having to invest in new hardware. **Improve performance** – Because containers use standard hardware and software configurations for operating systems and applications, they can be deployed at scale with no performance degradation. Because containers are stateless, they can be started and stopped quickly and easily, which improves the performance of multi-tenant applications. **Improve security** – Containers make it possible to run multiple applications on a single server without compromising the security of those applications. This helps organizations comply with regulations, thus reducing the number of potential attack points and simplifying compliance testing. **Improve application portability –** By packaging components into containers that are self-contained and independent from other components, you can easily move them between servers or data centers in case of a disaster or other disruption. This makes it easier to migrate to new hardware without having to worry about compatibility issues or dependencies between software components. **Reduce network latency** – Because each container is isolated from other containers on the same host server, latency is greatly reduced when compared to virtual machines hosted on the same physical server. This can lead to a significant increase in performance, especially when running multi-tenant applications where multiple users are trying to access the same server at the same time. **Reduce operational overhead** – Because containers are lightweight and use fewer resources than virtual machines, it is easier to scale your application horizontally by adding more servers to your environment. This means that you can easily handle peak traffic loads without having to worry about overloading your infrastructure. **Run legacy applications –** Containers allow you to run legacy applications written for older versions of operating systems on newer versions of the operating system with minimal effort, which makes it easier for organizations with older applications to migrate their environments to newer hardware and reduce their overall costs. ## Container Security With Kubernetes When it comes to securing your containers, there are several layers of fortification that Kubernetes offers and that you need to consider for a “defense-at-depth” approach. Both securing containerized applications and access to Kubernetes itself should be considered vital to IT security success. ### Kubernetes API Authentication & Authorization With the Kubernetes API being the central control unit of a Kubernetes cluster, it is vital to properly secure access to it. This can start with putting the Kubernetes API endpoint on a private network, but most importantly proper usage of authentication and authorization mechanisms is necessary. To authenticate a request (i.e. verify who is sending the request), Kubernetes offers several mechanisms: - TLS client certificates - OIDC - Service Account tokens - Static tokens To **authorize a request** (i.e. is the authenticated user allowed to perform the requested action), role-based access control (RBAC) is available. Roles can be assigned to users or groups and should only allow the bare minimum for an individual to perform their work. In particular, cluster-wide permissions should be closely guarded and assigned with caution. **Namespaces** allow for separating individuals or teams and their workloads and give cluster administrators the ability to limit RBAC permissions to a team’s logical unit of a Kubernetes cluster. Proper usage of namespaces can improve security by reducing the impact of credential compromise, as those can only access a small portion of the cluster and its workloads. [Read our blog post: Kubernetes Security Practices](https://www.kubermatic.com/blog/kubernetes-security-best-practices/) [Read our blog post: Improving Kubernetes Security With the CIS Benchmark and Kubermatic Kubernetes Platform 2.19](https://www.kubermatic.com/blog/improving-kubernetes-security-with-the-cis-benchmark-and-kkp-2-19/) **Securing Container Workloads** Apart from Kubernetes itself, of course container workloads can be secured beyond the defaults that Kubernetes offers when creating e.g. a Pod.For once, network access can be locked down via **NetworkPolicies**. These rulesets similar to firewalls allow defining restrictions both for external traffic to Pods, but also traffic between Pods in the same cluster. Apart from preventing attacks from the outside, proper usage of NetworkPolicies can drastically reduce the impact a compromised Pod can have on your environment. For example, if a Pod is not supposed to have any outgoing network connections, those can be prohibited via NetworkPolicies. In addition, Kubernetes offers a significant amount of optional settings for your workloads to tighten application security, disabling features that might not be needed (e.g. the container’s file system can be set to read-only to prevent writes) or improving the container sandbox beyond the default process isolation it provides. These partially depend on the application profile, so they might not be generally applicable, but should be reviewed and applied whenever possible. Compliance with specific rules for workload settings (e.g. all containers must run as a specific non-root user) can be enforced with tools like OPA Gatekeeper for keeping standards consistently used across an organization.  [Video: Kyverno vs. Open Policy Agent – Update Your Kubernetes Policy Management](https://youtu.be/SnIFU2MnrYU) ## What Are Container Platforms? Container platforms are software systems that provide a complete environment for running, managing, and orchestrating containers. Containers are lightweight, standalone, and executable units that include everything needed to run software, including code, runtime, libraries, and system tools. **Components of the container platforms:** - **Container Runtime:** The engine that runs and manages containers (e.g., Docker, containerd). - **Orchestration:** Tools and frameworks that manage the deployment, scaling, and operation of containerized applications (e.g., Kubernetes, Docker Swarm, OpenShift). - **Management Tools:** Interfaces and APIs for managing container lifecycle, networking, storage, and security. ## Why Use Container Platforms? **Efficiency and Resource Optimization:** Container platforms help optimize resources by running multiple containers on a single host without the overhead of virtual machines. This increases efficiency and reduces costs. **Consistency Across Environments:** Containers encapsulate applications and their dependencies, ensuring they run consistently across different environments — development, testing, or production. **Scalability:** Container platforms make it easier to scale applications. You can quickly launch new containers to handle increased loads and shut them down when they are no longer needed. **Isolation and Security:** Containers provide a level of isolation between applications, reducing the risk of security breaches. Each container runs independently, preventing one container from affecting others on the same host. **DevOps and CI/CD Integration:** Container platforms integrate seamlessly with DevOps tools and continuous integration/continuous deployment (CI/CD) pipelines, enabling automated testing, deployment, and updates. **Portability:** Containers can run on any system that supports the container runtime, making it easier to move applications across different environments and platforms without compatibility issues. ## How to Use Container Platforms? **Choose a Container Platform:** Popular container platforms include Docker, Kubernetes, OpenShift, and Docker Swarm. Kubernetes is the most widely used for orchestrating containerized applications. **Containerize Your Applications:** Begin by creating Docker images for your applications. This involves writing a Dockerfile that specifies the environment and dependencies needed to run your application. **Deploy and Manage Containers:** Use your chosen platform to deploy, manage, and monitor containers. Kubernetes, for example, uses YAML files to define the desired state of your application, including how many replicas each container should run. **Networking and Storage:** Configure networking to allow containers to communicate with each other and external services. Similarly, set up storage solutions to manage data persistence across container restarts. **Scaling and Load Balancing:** Leverage the platform’s capabilities to scale your applications automatically based on demand and distribute the load evenly across containers using built-in load balancing features. **Monitoring and Logging:** Implement monitoring and logging solutions to keep track of container performance and diagnose issues. Tools like Prometheus, Grafana, and ELK stack (Elasticsearch, Logstash, Kibana) are commonly used. **Security and Compliance:** Ensure that your containers and platform are secure by following best practices such as running containers with the least privilege, using trusted images, and regularly updating your containers and platform. **Automate with CI/CD:** Integrate your container platform with CI/CD pipelines to automate the building, testing, and deployment of containers, enabling faster and more reliable delivery of updates and new features. Using container platforms effectively can transform your development and deployment processes, making them more agile, scalable, and efficient. By understanding why and how to use these platforms, you can take full advantage of their capabilities to improve your IT operations and application delivery. ## Container Platform Examples **1. Docker** Docker is one of the most well-known and widely used container platforms. It provides a straightforward way to package applications and their dependencies into containers. **Key Features:** - Simplified container creation and management - Extensive library of pre-built containers in Docker Hub - Support for multi-container applications with Docker Compose - Integrations with various CI/CD tools **2. Kubernetes** Kubernetes is an open-source container orchestration platform designed to automate the deployment, scaling, and management of containerized applications. **Key Features:** - Automated scaling and load balancing - Self-healing capabilities to automatically replace failed containers - Rolling updates and rollbacks - Extensive ecosystem and support for multi-cloud deployments **3. OpenShift** OpenShift, developed by Red Hat, is an enterprise-grade Kubernetes container platform. It includes additional tools and features to enhance Kubernetes’ capabilities. **Key Features:** - Built-in CI/CD pipelines with Jenkins - Enhanced security and compliance features - Developer-friendly tools and user interfaces - Integration with Red Hat’s ecosystem and support services **4. Amazon Elastic Kubernetes Service (EKS)** Amazon EKS is a managed Kubernetes service by AWS. It simplifies running Kubernetes on the AWS cloud by handling the control plane management tasks. **Key Features:** - Managed Kubernetes control plane - Integration with AWS services like IAM, CloudWatch, and ELB - Scalability and high availability with AWS infrastructure - Simplified cluster provisioning and management **5. Google Kubernetes Engine (GKE)** GKE is Google Cloud’s managed Kubernetes service, offering a streamlined way to deploy, manage, and scale containerized applications using Kubernetes. **Key Features:** - Automated upgrades and patching - Integration with Google Cloud services like BigQuery and Pub/Sub - Enhanced security features like GKE Sandbox and Binary Authorization - Support for hybrid and multi-cloud environments with Anthos **6. Azure Kubernetes Service (AKS)** AKS is Microsoft Azure’s managed Kubernetes service, providing easy Kubernetes cluster deployment and management in the Azure cloud. **Key Features:** - Managed Kubernetes control plane - Integration with Azure services like Azure Active Directory and Azure Monitor - Simplified monitoring and scaling - Hybrid capabilities with Azure Arc **7. Rancher** Rancher is an open-source container management platform that simplifies Kubernetes cluster deployment and management across multiple environments. **Key Features:** - Centralized management for multiple Kubernetes clusters - User-friendly interface for cluster administration - Integrated monitoring, logging, and alerting tools - Multi-cloud and on-premises support **8. IBM Cloud Kubernetes Service** IBM Cloud Kubernetes Service offers a managed Kubernetes solution on IBM Cloud, focusing on security and integration with IBM’s cloud offerings. **Key Features:** - Managed Kubernetes with automated updates and scaling - Integration with IBM Watson and other IBM Cloud services - Enhanced security and compliance features - Global reach with IBM’s cloud infrastructure --- ## Service Mesh and Istio - **URL:** https://www.kubermatic.com/topics/what-is-istio/ - **Date:** 2023-03-28 - **Description:** Learn more about service mesh and istio. # Service Mesh and Istio ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Jump To Section [What Is a Service Mesh?](#what-is-a-service-mesh) [Benefits of a Service Mesh](#benefits-of-a-service-mesh) [How Does a Service Mesh Work?](#how-does-a-service-mesh-work) [Service Mesh Architecture](#service-mesh-architecture) [Open Source Service Mesh](#open-source-service-mesh) [Why Microservices Architecture Needs a Service Mesh](#why-microservices-architecture-needs-a-service-mesh) [What Is Istio?](#what-is-istio) [Why Use Istio?](#why-use-istio) [How to Implement Istio](#how-to-implement-istio) ## What Is a Service Mesh? A service mesh is a dedicated infrastructure layer like the open source project Istio, that controls how different parts of a distributed application share data with one another, without adding it into the application’s code. More precisely, service meshes control service-to-service communication in a microservices architecture to perform load balancing, deliver service requests to other services, encrypt data, and discover other services. A service mesh is composed of a **data plane** and a **control plane**. The data plane consists of intelligent proxies that are responsible to control all communication between the services. The control plane on the other hand acts as the brain of the mesh and controls the proxies. Or simple: the data plane forwards data while the control plan controls how this data is forwarded. [See More](/services/trainings/service-mesh/) ## Benefits of a Service Mesh Service meshes allow enterprises to deliver distributed applications at scale. The service mesh simplifies service-to-service based network operations like traffic management, load balancing, auditing, authorization and observability. The benefits of service mesh include: **Better service management:** With service mesh, the developer overhead is reduced as the networking operators can consistently manage networking for all of their services. **Enhanced security of services:** The network security operators can easily implement inter-service security including authentication, authorization, and encryption. **Improved application performance:** Service mesh enables development teams to implement best practices and get deep insights into their services. Teams can identify areas for improvement and focus on efforts to enhance performance.  **Managed traffic:** With service mesh, organizations will have control of traffic with rich routing rules, fault injection, refined policies, and more. **Simplified load balancing:** The proxies in the data plane work to scale and balance the load, so the applications don’t fail. The proxies communicate with each other without involving the services providing enough space for scale. **Easy deployment with Kubernetes and VMs:** Service mesh delivers network controls and visibility for traditional and modern workloads running in both virtual machines and containers. ## How Does a Service Mesh Work? The service mesh enables fast, reliable, and secure inter-service invocation in microservices architectures. Organizations can run microservices at scale with the help of a service mesh and get: - A more flexible release process - Availability and resilience - Secure communications More importantly, it is not a mesh of “services” but a mesh of “proxies” that services can plug into, hence abstracting the network from the application code. Let’s take a closer look at Istio, one of the most widely adopted service meshes: Istio is a Kubernetes-native mesh that uses the high-performance proxy [Envoy](https://www.envoyproxy.io/) that controls all inbound and outbound service traffic. It also uses a simple [Jaeger UI](https://www.jaegertracing.io/) for visualizing and storing traces to debug their microservices. Istio’s **data plane** comprises proxies, also known as sidecars, that control all the communication between microservices and generate telemetry on all traffic among services in the mesh. The **control plane** controls traffic by managing and configuring proxies based on the defined policies for that particular application within the mesh. The proxies are contained in each service as a sidecar through which the services communicate. Instead of invoking services directly, each of them invokes their local sidecar, which manages the requests on behalf of the services. This enables pushing the complexities of service communications into an infrastructure layer that can resolve them at a scale. ## Service Mesh Architecture A service mesh comprises two main components, a data plane and a control plane. **Data plane:** The data plane typically consists of a set of proxies, also known as sidecars. These proxies are responsible for mediating and controlling all network communication between microservices. In addition, the proxies collect and report telemetry on all mesh traffic. The main characteristics of data plane: - It issues policies and configurations by communicating with proxies. - It visualizes overall network behavior. - It provides an API for continuous integration and deployment. **Control plane:** The control plane is responsible for managing and configuring the proxies to route traffic. Here are some more characteristics of control plane: - It is designed to manage configurations and improve traffic forwarding performance. - Control plane functions, such as participating in routing protocols, run in the architectural control element. - It can be deployed easily as it is transparent to the application. ## Open Source Service Mesh There are several open source service meshes but the most popular and widely adopted ones are clearly [Linkerd](https://linkerd.io/) and [Istio](https://istio.io/).  Since, 2021, Linkerd is a [graduated project](https://www.cncf.io/projects/) of the Cloud Native Computing Foundation with 200+ contributors and 10,000+ stars on Github. Linkerd’s focus is on simplicity, security, and performance and is particularly suitable for highly-complex and large scale Kubernetes installations.   Istio is the Greek word for “sail”. It was initially developed by teams from Google and IBM in partnership with the Envoy team from Lyft. Just as Linkerd, more than 200 contributors contribute to the service mesh. Istio is platform-independent and open source under the [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0.html). ## Why Microservices Architecture Needs a Service Mesh The basic idea of microservice architecture is to split up a single application into a set of many loosely-coupled services, the so-called microservices. As these distributed applications become more and more complex, the requests between these services soar exponentially, requiring more sophisticated routing abilities to optimize the flow of data between the services and ensure the high performance of the application. Service meshes enable fast, reliable, and secure inter-service invocation in microservices architectures. Organizations can run microservices at scale with the help of a service mesh and get: - A more flexible release process - Availability and resilience - Secure communications ## What Is Istio? [Istio](https://istio.io/) is one of the most popular service meshes for distributed architectures. It allows developers to assemble apps using loosely coupled microservices to ensure portability in the cloud. In addition, Istio enables DevOps teams to manage the new cloud native apps within hybrid and multi-cloud environments. Istio is an open source and Kubernetes-native service mesh to automate network functions of distributed and containerized applications. It provides a uniform and more efficient way to secure, connect, and monitor services. In addition, the Istio service mesh also supports how those services communicate and share data. In a nutshell, Istio is the path to more efficient and standardized load balancing, service-to-service authentication, and monitoring with few or no service code changes. ## Why Use Istio? Istio enables organizations to secure, connect and monitor their distributed cloud native applications so organizations can modernize and migrate their services securely and hassle-free. From managing traffic flow between services to enforcing access policies, Istio service mesh does it all without requiring changes to application code. It also reduces deployment complexity by transparently layering onto existing distributed applications. Top features of Istio include: **Traffic management:** Istio uses routing rules to control the flow of traffic and API calls. This improves the reliability of the calls as well as the resilience of the network.  **Security:** With Istio, organizations can enforce policies consistently across multiple protocols and runtimes with very few application changes. For example, using Istio with Kubernetes network policies, the benefits include securing communication from pod-to-pod or service-to-service at network and application layers communication in a cluster with TLS encryption, authorization and robust identity-based authentication. **Observability:** The tracing, logging, and monitoring features of Istio help you get insights into your service mesh deployment. Through consistent monitoring, organizations can consider how service activity influences upstream and downstream performance. In addition, custom dashboards offer great visibility for performing all the services. **Expendability:** Istio is designed for expansion and can handle various deployment needs. Istio’s control plane runs on Kubernetes and contains a variety of elements. Development teams can add applications deployed in that cluster to the mesh, expand it to other clusters, or even connect VMs or other nodes running outside of Kubernetes. ## How to Implement Istio Implementing a service mesh in your organization comprises setting up the control plane components, preparing the data plane by injecting Envoy proxies as sidecars to each service instance, and connecting them to the control plane. DevOps teams can then easily configure the service mesh behavior from the control plane by utilizing policies. Of course, service mesh implementation depends on the platform you choose, but it will determine the exact steps involved. Istio service mesh implementation is simplified by combining control plane components and data plane executables, eliminating the need to deploy them individually. When installing Istio on Kubernetes, there are two modes of data plane available, traditional with sidecars and sidecarless called Ambient mode. With the traditional mode, it is easier to create the data plane entities as the proxy sidecar can be deployed automatically along with each service labeled. The proxy is manually installed along with each service and registered with the control plane on the virtual machine. Policies are used to configure the behavior of the service mesh and get desired outcomes to process application layer. Ambient mode is designed for simplified operations, application compatibility, and reduced resource usage on the cluster, simply offering a shared ztunnel agent, running on each node in the Kubernetes cluster, that serves as a secure overlay that handles routing and zero trust security for traffic. When needed, you can enable application layer processing per namespace to get access to the full range of Istio features by deploying waypoint proxies. --- ## Kubernetes - **URL:** https://www.kubermatic.com/topics/kubernetes/ - **Date:** 2024-08-12 - **Description:** Everything you need to know about Kubernetes, how this technology works and what the benefits of Kubernetes are. # What is Kubernetes? ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Jump To Section [What is Kubernetes?](#what-is-kubernetes) [What are Kubernetes Clusters?](#what-are-kubernetes-clusters) [What is Kubernetes cluster management?](#what-is-kubernetes-cluster-management) [What are Kubernetes’ Key Benefits?](#what-are-kubernetes-key-benefits) [Who Develops Kubernetes?](#who-develops-kubernetes) [Introduction to Kubernetes Architecture](#introduction-to-kubernetes-architecture) [How Does Kubernetes Work?](#how-does-kubernetes-work) [Kubernetes Management Strategies for High Scalability](#kubernetes-management-strategies-for-high-scalability) ## What is Kubernetes? The success of your business today relies to an ever increasing extent on the applications that are running on your IT infrastructure. Like the finest symphony ever created to delight and engage its audience requires an excellent conductor to evoke the best from every member of the orchestra, the most dynamic enterprises recognize the value of Kubernetes to manage not only today’s containerized applications, the soloists featured in the performance and lifeblood of a company’s value and reputation, but all of the musicians which represent the diverse, supporting infrastructure. Kubernetes is a highly sophisticated tool to orchestrate all of your applications, with automated deployment and control whether you’re using public clouds, on-prem or edge infrastructures, as well as any combination of these. It is the distribution manager for workloads in a cluster, automatically adjusting the dynamic networking requirements for all containers. Often referred to as “k8s”, Kubernetes also manages the allocation of storage and persistent volumes, and automates scaling to provide maximum reliability and availability. [See More](/categories/kubernetes/) ## What are Kubernetes Clusters? Kubernetes clusters are basically a **group of nodes** that run applications that have been containerized, and include whatever services and dependencies that app requires. With Kubernetes clusters, containerized applications can be managed across any virtual, physical, cloud-based or on-premises environment or combination thereof.  A Kubernetes cluster has what’s called a master node and worker nodes, all of which are either virtual or physical machines. The **master node** serves as the control plane of the cluster, constantly managing the actual state of the cluster to its defined, desired state. The master node coordinates all tasks including the scheduling and scaling of applications, executing updates, and automatically maintaining  the desired state of the cluster. The **worker nodes** host the components that are necessary for deploying and running the containerized application. They’re called worker nodes because they execute the tasks assigned to them by the master node.  A functional Kubernetes cluster has at least one master and one worker node.   In addition, users can deploy so-called **namespaces** to arrange multiple clusters in a single physical cluster. Namespaces are Kubernetes objects that separate Kubernetes clusters into multiple virtual ones, which allows users to allocate resource quotas to specific teams or projects. [See More](/resources/kubernetes-101-introducing-kubernetes/) ## What is Kubernetes cluster management? Kubernetes cluster management is a process of managing and orchestrating multiple containers across a network or a cluster of machines. This enables developers to easily deploy and manage their containerized applications. With Kubernetes, you can run and scale applications and services using the same infrastructure, making it easier to manage and maintain. Additionally, Kubernetes offers features like automatic scaling, load balancing, and self-healing, making it a highly efficient and reliable platform for managing clusters of containers. Kubernetes cluster management allows developers to easily deploy, manage, and scale applications and services in a more efficient and automated manner. It simplifies the complex process of managing containers, ultimately increasing productivity and reducing operational costs. ## What are Kubernetes’ Key Benefits? Kubernetes is an open source platform that manages containers so that applications are available 24/7 and new versions can be deployed anytime without downtime, running wherever and whenever you want with the resources and tools that are required to get the job done. Its many features include: ##### **Flexible, Automatic Scaling** Via the user interface command or automatically, based on CPU usage for the best use of existing resources. ##### **Availability/Self Healing** Containers are automatically restarted when they fail and disabled when not compliant to existing health checks. Non-functioning nodes are automatically replaced and rescheduled to provide maximum resiliency. ##### **Storage Orchestration** Kubernetes allows you to add the storage system of your choice automatically including local storage, public cloud providers, and many others. ##### **Service Discovery & Load Balancing** Service discovery is essential if you run a microservice architecture. Kubernetes assigns each pod an IP address and each set of pods a DNS name, so that you can easily discover your services. If a container has too much traffic, Kubernetes can load balance and provide you with superior stability. ## Who Develops Kubernetes? Originally developed and designed by engineers at Google, Kubernetes has evolved into the most popular container management system, thanks to its truly open source platform. This has also resulted in significant, ongoing contributions from the open source community and the [Cloud Native Computing Foundation](https://en.wikipedia.org/wiki/Cloud_Native_Computing_Foundation), which currently maintains the project. ## Introduction to Kubernetes Architecture A Kubernetes Cluster has: - a control plane, referred to as the master node, - one or more worker nodes that run containerized applications. The Master Node is at the center of the K8s cluster, manages it and provides access to the API. It contains the cloud-controller-manager, etcd, the kube-controller-manager, the kube-api server, and the kube-scheduler. ##### **Control Plane / Master Cluster Components** Cloud-controller-manager The cloud-controller-manager controls the cloud-specific logic. It connects your clusters with your cloud provider’s API and makes sure that the right components interact with the underlying cloud infrastructure.   Etcd The backing store for all cluster data is etcd, a key value store that also replicates the state of the Kubernetes cluster. Once you have created a Kubernetes cluster and configured the command-line tool to communicate with it, you can run etcd; just take the extra step and create a backup plan for that data. Kube-controller-manager This component is part of the control plane that manages controller processes. Controllers are organized into a single binary, so that they run in one simple process, although strictly speaking, each is in fact its own separate and distinct process. Controllers within this manager include: - Node controller: controls the activities of the nodes - Endpoints controller: ties together services and pods by populating Endpoints objects - Job controller: monitors one-off tasks and generates pods to complete them - Replication controller: maintains object replications in the cluster - Service Account & Token controllers: provision default accounts and provide API access tokens when a namespace is created Kube-apiserver The Kube-apiserver exposes the Kubernetes API. It scales horizontally by creating additional instances, and if you have several instances, the traffic can be managed between them.  Kube-scheduler Any Pod that has been created without an assigned node is detected by Kube-scheduler, which then determines and selects one for that Pod. This decision is made based on several criteria, including workload and policy limitations, deadlines, as well as the resources required. ##### **Nodes** A node is either a physical or a virtual machine that holds and has the components required to run pods and is managed by the control plane. There are two distinct types of nodes in Kubernetes, Master and Worker. Master nodes support the control plane elements of a cluster, manage worker nodes and are responsible for API endpoints for users and scheduling for pods across available resources. Workload distribution and the state of the cluster is managed by the master node. Worker nodes are used to run containers and perform tasks assigned by the Master node. They process the stored data and communicate with the master about resources. Kubelet The kubelet is a node component that oversees the operation of all cycles of each node within every pod. It looks after the health of each pod by checking new or altered specs created by the master nodes and makes sure that its state corresponds/agrees with its specifications. Kube-proxy Each node runs Kube-proxy, which is a network proxy that keeps track of the rules that allow for communication sessions to Pods inside or outside of a cluster. It is used for load balancing and to reach Kubernetes services. ## How Does Kubernetes Work? Kubernetes is an open source system that manages containers to accelerate the deployment, scaling and administration of applications. It creates a set of components that provide these activities based on either memory, CPU or specially designed measurements. All elements that form a part of or run on Kubernetes are tied into the Kubernetes API. The platform controls compute and storage resources by classifying and managing them as objects.  A fundamental concept at the heart of Kubernetes is its ability to constantly attempt to match the state in which your containers are actually running with your desired state. This approach, based on declaring your desired state and Kubernetes’ capability to continually monitor and correct for it, is why it‘s so popular with DevOps for application lifecycle management. ## Kubernetes Management Strategies for High Scalability There are several Kubernetes management strategies that can help you achieve high scalability for your applications: 1. **Horizontal Pod Autoscaling**: This strategy allows Kubernetes to automatically scale the number of pods based on CPU utilization, ensuring that your application can handle increasing user demand. This helps in maintaining a balance between cost and performance. 2. **Cluster Autoscaling**: This strategy allows Kubernetes to scale the number of nodes in a cluster based on resource utilization. This is particularly useful for applications that have variable workload patterns. 3. **Vertical Pod Autoscaling**: This strategy adjusts the CPU and memory resources allocated to a pod based on its actual resource utilization, allowing for better utilization of resources and improved application performance. 4. **Rolling Updates**: Kubernetes allows you to update your application without any downtime by gradually rolling out updates to a single pod at a time. This ensures that your application remains available and can handle high traffic during updates. 5. **Fault Tolerance**: By using Kubernetes features like ReplicaSets and self-healing mechanisms, you can ensure that your application remains available even if some of the pods fail. 6. **Multiple Clusters**: Another strategy is to run multiple clusters for your application, allowing you to isolate and scale different parts of your application separately. This can help you handle highly complex and large-scale applications more efficiently. By implementing these strategies, you can ensure high scalability for your applications running on Kubernetes. It is important to regularly monitor and analyze your application’s performance to identify potential bottlenecks and optimize your Kubernetes setup for even better scalability. --- ## Managing External Kubernetes Clusters With KKP - **URL:** https://www.kubermatic.com/blog/why-we-decided-to-support-external-kubernetes-clusters-via-api/ - **Date:** 2026-05-07 - **Description:** Learn more about External Kubernetes Clusters. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Mita Bhattacharya ## **Short Summary** * **Who should read this article?** * KKP Admins, Architects and Developers using the KKP Dashboard * Anyone who wants to run large scale infrastructure on multiple clouds * **What pain points are we addressing?** * Multiple dashboards can be confusing to access. In response to this challenge, KKP 2.19 allows users to access AKS, EKS, and GKE clusters directly from the KKP Dashboard. * **What can you expect from this content?** * In this blog, we describe how users can add their AKS, EKS, and GKE clusters to KKP, the method by which we enabled this feature and the benefits users can expect as a direct result of this implementation. ## **Introduction** Kubernetes clusters are becoming an integral part of how businesses operate. As organizations continue to grow, it becomes increasingly important to have a scalable IT infrastructure that can keep up. Multi-cluster deployments are one way to overcome this challenge. By using the Kubermatic Kubernetes Platform (KKP), businesses can manage a multitude of clusters effectively and efficiently. Additionally, Kubernetes clusters are now being run on multiple platforms. Our goal is to make it easier for customers to monitor and manage these external clusters. ## **What Are External Kubernetes Clusters (AKS, EKS & GKE), and Why Do They Matter?** The 2021 CNCF survey found that the three most popular Kubernetes hosted platforms are Amazon Elastic Container Service for Kubernetes, **Azure Kubernetes Services (AKS)** and Azure (AKS) Engine. After several discussions, we realized that many of our customers, prospects and users already have clusters in **Amazon Elastic Kubernetes Service (EKS)** and in the **Google Kubernetes Engine (GKE)**. Our prospects and customers would like to use the **Kubermatic Kubernetes Engine (KKP)**, but they don’t want to disrupt their existing workloads on other platforms. In order to keep track of these workloads, they would have to refer to the KKP dashboard, as well as the external dashboards.  Flipping from one dashboard to another is counterintuitive, and defeats the whole purpose of the dashboard! So we decided to provide a solution that initially will allow our users to view, import, and manage their existing clusters on EKS, AKS, and GKE. Our users can continue to take advantage of the innovative products from these hyperscalers with the added convenience of managing the clusters within KKP directly!  The benefits of this implementation are clear. By being able to view all of their clusters in one place, users can save time and improve efficiency. Additionally, by having a single point of contact for all cluster management tasks, users can minimize the risk of human error. ## **What Made Us Choose An API-First Approach?** The rise of Kubernetes as an orchestration platform meant the need for quicker and more stable methods for the deployment and development of applications. Thanks to new technologies like Edge and IoT, data needs to be exchanged between platforms ever faster. To take full advantage of cloud architectures, monolithic applications must be reworked, first into microservices, and then as APIs that are easily managed and developed, increasing the importance of a highly manageable API infrastructure. At its core, KKP is built around efficiency and performance. As such, API management as an essential feature that helps us leverage the inherent advantages of Kubernetes’ most powerful elements - its APIs. This enables you to create better design patterns that permit improved monitoring, enhanced workflows, and architectural designs that are sustainable, scalable, and flexible throughout the application lifecycle.  At the heart of KKP is the principle of expanding Kubernetes capabilities. By adding the power of Kubermatic's APIs, we’re able to deliver more predictable patterns, easier adoption and development of new features, as well as the ability to create your work API paths for your own use cases, creating a vastly superior and personalized user experience. Managing an external Kubernetes cluster requires a minimum of 20 mCPU and 40 MB RAM. This consumption ultimately translates into a cost for the users, which is neither justified nor beneficial, and a lean implementation is therefore mandatory. Sidecars deploy relatively quickly and are scalable. Implementing sidecars, however, means increasing the number of clusters that we need to monitor, manage, and control. It’s clear that sidecars don’t meet our needs for a long-term, scalable and manageable system. APIs are reliable, consistent, and almost everyone has used them. Both from a development and usage perspective, this minimizes the risk of failure. Likewise, cluster detachment has no effect on managed or on managing clusters. ## **How to Manage Your External Kubernetes Clusters with KKP** KKP doesn‘t require any additional steps like installing external controllers or agents. We rely on provider-client, which allows us to fully manage the clusters. The user with the proper credentials can immediately start managing the native clusters in the KKP. With KKP 2.19, users can: 1. Import AKS, EKS and GKE clusters. ![Adding external clusters to the KKP dashboard](/static/adding-external-clusters-to-the-kkp-dashboard-blogpost.png) ![Importing external clusters with Kubermatic Kubernetes Platform](/static/importing-external-clusters-with-kubermatic-kubernetes-platform-blogpost.png) 2. View the status of external Kubernetes cluster endpoints that indicate their current state. ![Imported AKS Cluster](/static/imported-aks-cluster-blogpost.png) 3. View external Kubernetes cluster details, cluster machine deployments and machine deployment nodes of the above mentioned external clusters. ![Events for the imported cluster](/static/events-for-the-imported-cluster-blogpost.png) 4. Manage the lifecycle of the external Kubernetes clusters: Create, Delete, Upgrade, Cluster & Node Deployments, and Scale Node Deployments. ![Upgrade the Control Plane Version on availability](/static/upgrade-the-control-plane-version-on-availability.-blogpostpng.png) 5. Edit replica count for external Kubernetes clusters. We are really excited to release this new functionality and would love to hear what you think. Managing Kubernetes clusters can be a daunting task, but with this update, you can now control your external clusters from the dashboard, giving you more flexibility and greater ease of use when managing your installations. If you'd like to find out how KKP can help you achieve  your business goals, [get in touch with us](https://www.kubermatic.com/contact-us/)! ## **Learn More** * Read more about external cluster management [here](https://docs.kubermatic.com/kubermatic/v2.19/tutorials_howtos/external_clusters/) * Check out what‘s new with [KKP 2.19!](https://www.kubermatic.com/blog/kubermatic-kubernetes-platform-2-19-is-ga/) * Did you know KKP 2.20 is out? Read more about it [here](https://www.kubermatic.com/blog/kubermatic-kubernetes-platform-2-20-is-ga/) --- ## A Guide to the Kubernetes Ingress Controllers - **URL:** https://www.kubermatic.com/blog/a-guide-to-the-kubernetes-ingress-controllers/ - **Date:** 2026-05-07 - **Description:** Learn more about what Kubernetes Ingress Controllers are and how to use them in this short guide. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Mita Bhattacharya Kubernetes is a cloud-native open-source system for automating the deployment, scaling, and management of containerized applications. It is often employed to automate applications used for running businesses or as a system to manage application products. Kubernetes is widely adopted and has a largely positive reputation among companies and developers. In this guide, we’ll look at the Kubernetes ingress controllers, the workhorse of Kubernetes routing. We’ll go over what they do and how to use them, and explore k8s Ingress. ## **What Is Ingress?** Ingress is a relatively new feature to Kubernetes that is gaining popularity because of its usefulness. It enables developers to allow outside users to send requests to services that you have running in Kubernetes. Normally, doing so is not possible since Kubernetes protects your clusters from external traffic. #### **Background** Kubernetes is an open-source system for managing clusters of containerized services. These processes can be anything from worker roles on your computer to entire applications, depending upon how you want them set up! It is not uncommon for a service to include pods on multiple servers in different locations that do related tasks and help each other reach a desired goal. When you set up this service, you can send requests to it and receive the results when it is done.  Normally, using a service would require a connection to your Kubernetes cluster to access it, which isn’t possible for outside users under normal circumstances. Ingress addresses this problem. #### **How Ingress Works** Ingress creates a resource that is exposed to the outside world and connected to your Kubernetes cluster. When someone wants to use your service, they send a request to the ingress, which then pulls it into the cluster and routes it to the service.  This is very similar to how an API works, but ingress helps keep your Kubernetes clusters safe by limiting their exposure to outside resources and services. Every ingress consists of the resource it creates, and a set of rulers uses the ingress controller to route incoming traffic. ## **Why Is Ingress So Important?** Ingress is important because it renders your apps usable by outside resources without exposing them to potentially malicious outside traffic. The apps that you build are meant to be used by other systems, but the way that Kubernetes functions makes that difficult without potentially exposing everything to risks. Ingress bridges the gap between exposure and security by giving that traffic a way in without leaving the gates fully open. It is much easier to implement security on this one inlet than the entire app.  Ingress also gives you more detailed control over how other systems access your services. Ingress controllers use a set of rules that you set up in a YAML file to determine how traffic is routed. When done right, you can grant access to multiple services based on how the ingress is accessed or a specific service under specific conditions. ## **What Are Ingress Controllers?** An ingress controller is, in a nutshell, a load balancer that lets traffic into your Kubernetes cluster with a set of rules to route the traffic. When used, all traffic through the ingress goes through the ingress controller. The controller listens for specific conditions and cues, then processes that connection based on your established rules.  In essence, the ingress controller is the most essential part of your ingress implementation. It gives you control and lets you manage the use of your services and resources to improve performance. It may technically be possible to establish an ingress without a controller, but the lack of control would mean that you cannot dictate how your service is used once the connection is made. ## **Ingress Controller Types** Ingress controllers have multiple forms. These include third-party options, like NGINX, which streamline the process and make it easier to use. These ingress controllers handle all aspects of ingresses so that setting them up and using them is easier. However, you can do all of this yourself without a controller.  Using a controller is likely the better option in a multi-person development environment due to the increased reliability and standardization that you get from implementing a common system. #### **How Ingress Controllers Work** Kubernetes ingress controllers are Kubernetes resources that handle HTTP traffic and direct it to an appropriate backend, such as an application server. Ingress controllers are responsible for creating reverse proxies and forwarding requests to the applicable service. They use a variety of health checks to ensure that requests are correctly routed. The most common type of ingress controller is a NodePort, which exposes a node’s port on the host machine so you can access it from outside the cluster. ## **Use Cases for Ingress Controllers** Ingress controllers streamline the creation and management of an ingress, which is beneficial when multiple developers are involved in the process. There are several ways you can use the controller to manage routing to services. #### **Give Access to Services Securely** Ingress controllers create a connection to your services through HTTP and HTTPS routes rather than allowing a direct connection. This lets you set up the best route for your needs and seal off all other possible options. #### **Create Access Routes for Multiple Services** Since you have control over the route to a service, you can set up the criteria for accessing it. That means that you can route traffic based on certain conditions and route traffic to different services accordingly. Rather than having many open connections to access your app, which makes security and load balancing difficult, you can have one route that changes based on certain conditions to get traffic where it needs to go. #### **Streamlining Complicated Ingress Process Management** Managing access to multiple services on your app can be complex. Using an ingress controller makes the process much simpler. It brings all of the processes into a single system, making it easier for you to manage access for multiple services in less time and with less hassle. This can make a considerable difference in performance and management costs for large-scale systems. ## **Start Using Ingress in Kubernetes** Kubernetes ingress controllers are an important part of your Kubernetes infrastructure and help provide secure access to your Kubernetes clusters and applications. There are several ways to achieve similar results through Kubernetes, but ingress is quickly becoming the leading option for this sort of service access.  Ingresses are the keys to adding third-party resources to your apps without compromising security. It is worth the time and effort to learn to use ingress effectively since it can significantly impact the functionality of your next project. ## **Learn More** * Blog Post: [Introduction to Kubernetes Deployment](https://www.kubermatic.com/blog/introduction-to-kubernetes-deployment/) * Blog Post: [Introduction to ReplicaSet](https://www.kubermatic.com/blog/introduction-to-kubernetes-replicasets/) * Video: [How to Write Software That Sets Up Kubernetes Anywhere](https://www.kubermatic.com/resources/how-to-write-software-that-sets-up-kubernetes-anywhere/) --- ## Kubermatic March News! - **URL:** https://www.kubermatic.com/blog/kubermatic-news-for-march-2022/ - **Date:** 2026-05-07 - **Description:** Joining forces with SVA Software Inc., lots of cool new features in KKP and KubeOne and free passes for KubeCon Europe Virtual. - **Categories:** Company - **Tags:** Announcements - **Authors:** Sebastian Scheele It’s been a while since we last updated you on everything that’s happening at and around Kubermatic…the past few months have been wild but productive: Getting new partners onboard, releasing Kubermatic Kubernetes Platform (KKP) 2.19 and 2.20 and KubeOne 1.4, preparing for KubeCon Europe and ContainerDays,...but take a look yourself and enjoy reading! I hope you like the resources and information that we have put together this month. Your feedback is always appreciated. ## **Company News** ### **We’re Going Overseas – Joining Forces With SVA Software, Inc.** With the recently announced strategic partnership with [SVA Software, Inc.](https://cxwn804.na1.hubspotlinks.com/Ctc/LW+113/cxWn804/MW568LfPdl8W4VRR7N7T3htBW7swsJQ4G_jD7N6YWdrZ3lSb9V1-WJV7CgPlNN7qYX4WM_W31W7n94hg3qnPq5W5m4VVG8xlxvmW6Pm2mm8Q62mLN2D82pmYkFQjW47nh_08mwFpyW51y-806cQq-kW7SVr8F3sH3CNW1_grl98QPq2lW3b-zDm1GMbZjW3Qkm5m6Kdz_zW5LLcHp8ZgPykVrmQgr996NxrW8thLSg8LzddnW7wpl2C1GnblQW29FZzV5jPSKPW3BTK935MJpVRW11s_1w30dQ0k35n-1) — the US-based subsidiary of [SVA System Vertrieb Alexander GmbH](https://cxwn804.na1.hubspotlinks.com/Ctc/LW+113/cxWn804/MW568LfPdl8W4VRR7N7T3htBW7swsJQ4G_jD7N6YWdrZ3lSb9V1-WJV7CgC17W65bs-x1VqxTZW6dDFH_8HGx5NW6FyJ5K7ZCHmxV2KDG83cYyGYW5v_gN-98g_gtW7hLXPz6nWSJ5W1rQXT_5trp8WW237xXD20cyyRW7kwKCZ5QNddFN7fc76hJyFF1N6ZScS1sprYzW4HTG9v48Qx0yN4K7L-0ZWdXlW7M6QT571QmVTW62YfWY59dS1_W2zdRFX2h9PzmN53xdJlXGVPFVBHlvK81vXXH3hF11) (Germany’s largest privately owned systems integrator in the fields of Datacenter Infrastructure and largest IBM business partner in Europe), we’re delighted to expand the successful joint projects in Central Europe to North America and help businesses empower their infrastructure. [Read the Announcement Post](https://www.kubermatic.com/blog/joining-forces-with-sva-software-inc/) ## **Product News** ### **Best-in-class Networking With Cilium CNI and Many More New Features in KKP** Quite some news on the product side! Did you know that you now can choose between the two most popular CNIs Canal and Cilium or simply add and manage the CNI of your choice? With the KKP 2.19 release, we introduced out-of-the-box [Cilium CNI](https://cxwn804.na1.hubspotlinks.com/Ctc/LW+113/cxWn804/MW568LfPdl8W4VRR7N7T3htBW7swsJQ4G_jD7N6YWdrZ3lSb9V1-WJV7CgKsVW525txx7fQ-ZzW3Q2M2d8t5qGqW2vjsvC9m2gZMW3w40f323v1DgVW-plx5lt4MsW62JN-95mL-FLW2N9nnT5JZVPXW36qvvW7f585lW6Y1t495N9w9pVYFcBv9k8HCSW306dnz1fypzwW7-0R_B5k8j-PW72zTHP8zCJFYW3C6nhR6D2Z0xW8jk2R549TMy4N1YJK4TKB5yBW1jlDXl5MVp48W7WNVsf977GXr32Zp1) support and integrated the [Hubble add-on](https://cxwn804.na1.hubspotlinks.com/Ctc/LW+113/cxWn804/MW568LfPdl8W4VRR7N7T3htBW7swsJQ4G_jD7N6YWdsy3lSbNV1-WJV7CgDk9W2-8mr75HD76MW2_wGYz1m7TL-W7399ND7DD6psW6hGm2z5WFxddN2F0gz1b7VXKW3NkXwF6Bh7k5N9jr2nv7JYmXN9hm6pkHbV-ZW9dp9PH39gwpKN17-lsVssc-0W3hrZbh6BpDsBN3S3LjJDM9RXVsTdpd9ffhnJW572Pct4BG4GqN4CyVjXZSRKKW7ng40L6KkK4RW3K9sjS4jHxpcN4W-ppN8XfgSN7l4kCKyT05wVmCN4z3n-ZjgW1Gm3vM23crK8N8XvbqbDXncZ373W1) so you can observe your network and security with complete transparency from the Hubble UI. [See KKP in Action](https://www.kubermatic.com/resources/kubermatic-kubernetes-platform-kkp-2-19-highlights/) …and there’s a bunch of more exciting new stuff to check out in KKP 2.20. Nutanix HCI for example is now on our list of out-of-the-box providers! [Read the Release Post](https://www.kubermatic.com/blog/kubermatic-kubernetes-platform-2-20-is-ga/) ### **Curtain Up for KubeOne 1.4!** With the latest release, we introduced a **new KubeOneCluster API version** with many features that simplify configuration management. Additionally, we have added **support for Kubernetes 1.23** **and Cilium CNI and simplified CCM/CSI migration**. Plus, KubeOne 1.4 now also provides alpha-level **support for Nutanix**. [See What’s New in KubeOne](https://www.kubermatic.com/blog/meet-kubeone-1-4/) ## Kubermatic Blog * [Get the Best of Both Worlds With the KKP 2.19 CNI Strategy](https://www.kubermatic.com/blog/get-the-best-of-both-worlds-with-the-kkp-2-19-cni-strategy/) * [Azure Resource Optimization](https://www.kubermatic.com/blog/azure-resource-optimization/) * [Improving Kubernetes Security With the CIS Benchmark and KKP 2.19](https://www.kubermatic.com/blog/improving-kubernetes-security-with-the-cis-benchmark-and-kkp-2-19/) [Discover Our Blog](https://www.kubermatic.com/blog/) ## **Resource Library** ### **Free Guide: Why Kubernetes Management Needs a Seat at the Strategy Table** In the quest for superior **speed, agility, and scalability**, businesses around the world are adopting Kubernetes. At the same time, deploying Kubernetes in complex enterprise environments comes with its own set of challenges. In our **free guide**, we’ll provide you with everything you need to know to **build a Kubernetes master plan that is designed for success**. [Download Our Free Guide](/resources/why-kubernetes-adoption-needs-management-endorsement/) ## **Events & More** ### **Meet Us at KubeCon Europe** 📅 May 16-20, 2022 📍 Valencia and online This will be fun – **double #powerthroughautomation at our booth**! Together with our partner [SVA System Vertrieb Alexander GmbH](https://cxwn804.na1.hubspotlinks.com/Ctc/LW+113/cxWn804/MW568LfPdl8W4VRR7N7T3htBW7swsJQ4G_jD7N6YWdrZ3lSb9V1-WJV7CgSczW3_SJ-S2FZkn1W5ck0kJ5T6CFWN1b6YhzdsLzlW5r4SWB5-3J27W87Vpcv27NFGMVQVCs12LTlBGW8CJRfN4HQjMSW3D0RQ57MynFwW4GPrnR54D6wMW3HHVcc8gQrndW6Jd5VF6mpS0BW5qPjd177XrkMW7Vbptv8QVxjjW4l1JNm5P9Dw_W1Pnwmy6KlgMVW74c0gC2fy0P5N7txFQz1rl3FMYMdhRRxVJw38nt1), we can't wait to meet you in person and share our knowledge on #Kubernetes, #opensource projects and much more at the Cloud Native Computing Foundation’s flagship conference. There’s a lot of cool stuff we’re planning for you, don’t miss it:) P.S.: As a Silver Sponsor, we have some **20% vouchers** for the onsite conference in Valencia plis  **free passes** for the virtual event available. The first 5 to answer this email with a big HERE get one. [Join Us at KubeCon](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/register/) ### **Save Your Super Early Bird Ticket for ContainerDays 2022** 📅 September 5-7, 2022 📍 Hamburg and online Speaking of events…have you already saved your seat for **ContainerDays (CDS) 2022**? Europe’s flagship conference will offer you a great learning experience on **\#Kubernetes, #CloudNative, #DevOps, #GitOps, #EdgeComputing** and much more. This is your opportunity to meet and exchange with other cloud native enthusiasts from across the globe in person  virtually. Be quick – our **super early bird offer ends on March 31**! Don’t miss your chance to only pay €299 instead of the regular €599. [Grab Your CDS Ticket](https://tickets.containerdays.io/) --- ## Kubernetes User Cluster Network Performance in KKP - **URL:** https://www.kubermatic.com/blog/striving-for-the-fastest-response-times-in-kubernetes-clusters/ - **Date:** 2026-05-07 - **Description:** Benchmark of network tools in a cluster powered by Kubermatic Kubernetes Platform. - **Categories:** Products, Best Practices - **Tags:** KKP, Kubernetes - **Authors:** Csenger Szabo ## **Short Summary** This post is for architects, DevOps people to: * Address the importance of using the correct setup of different network tools in Kubernetes clusters and Kubermatic Kubernetes Platform (KKP) * In order to avoid a bottleneck in the IT infrastructure that affects response times ## Quick Network Response Times Have Become the Standard 33 milliseconds - The amount of time needed for a piece of information to travel from Spain to the U.S. and back via the Marea undersea cable. This is part of the technology today that enables high-speed and high-definition communications all over the world. Quick response times have become a standard end-user expectation, so the speed of communications inside IT infrastructures can’t be bottlenecked.  This has to be considered when IT infrastructures are being designed and operations are being optimized. It means that we have to evaluate and decide on suitable tools for networking in Kubernetes clusters and in the Kubermatic Kubernetes Platform. We’ve done a lot of benchmarking to see which setup performs the best. ## The Toolset for Network Benchmarking in Kubernetes #### **Baseline** Two things had to be decided before actual benchmarking: * The tools and use cases we wanted to evaluate as benchmarking subjects * Which tools would help us perform the actual measurements #### **Applied measurements** First, we measured the time required to create pods in the Kubermatic Kubernetes Platform based on various numbers of pods and nodes. This was independent of the tools used to communicate between the clusters, but part of optimizing the cluster for better response times. We wanted to determine the relationship between a pod’s start up time with various amounts of node and pod setups. Second, by measuring the internal communications in a cluster, we compared the performance of different Container Network Interface (CNI) platforms like Cilium and Canal to the Kubernetes user cluster network performance in the Kubermatic Kubernetes Platform. Last but not least, for control-plane to cluster connections, we compared how OpenVPN and Konnectivity perform when applying APIServer to node communication benchmarks. OpenVPN and Konnectivity are needed because of the [unique architecture](https://docs.kubermatic.com/kubermatic/v2.16/concepts/architecture/) of the Kubermatic Kubernetes Platform (KKP). Basically, Kubernetes control-plane components are detached from the workload and are present in two different clusters; workload exists in user clusters, while control plane components live in the master / seed cluster. This allows us to utilize as many resources as needed for the actual workloads, and create several, more efficient Kubernetes clusters that work together. At the same time, we keep the latency as low as possible, with OpenVPN and Konnectivity being responsible for the connection between the master / seed cluster and the user clusters. #### **Benchmarking tools** We used [Kubernetes Netperf](https://github.com/kubernetes/perf-tests/tree/master/network/benchmarks/netperf) which includes *iperf*, and we added *qperf* support to it. Because these can’t benchmark Konnectivity, we also built [Benchmate](https://benchmate.org/) for the measurements. ## Benchmarking of the Kubermatic Kubernetes Platform #### **Kubernetes pod creation time** The table below shows the average latency in milliseconds to get pods up and running. This benchmark was created on a cluster that contained nodes with 2 CPUs and 2GB of RAM memory. ![The average latency in milliseconds to get pods up and running](/static/image1-network-benchmark-wip-blogpost.png) As you can see, a higher proportion of pods / nodes results in greater latency when starting up those pods. #### **Kubernetes cluster communication performance between nodes and pods** We measured throughput and latency values in different setups for the cluster communications benchmark. As previously mentioned, Cilium and Canal are part of this benchmarking. \ In the table below, you can see the throughput differences between the 2 tools in various setups. Values were calculated based on the message throughput of Cilium minus the throughput of Canal. If there is a positive value in a red cell, Cilium is the winner, because it has a higher throughput value in that particular setup with its message size. If, however, there is a negative value in a blue cell, Canal has a higher throughput there. The platform with a higher throughput performs better in different cases. This measurement was taken on multiple Amazon EC2 t3a.xlarge virtual machines with 4 CPUs and 16GB of RAM memory, and made by qperf where the throughput difference is in MB/sec. ![Differences between the Cilium and Canal in various setups](/static/image2-network-benchmark-wip-blogpost.png) The next measurement shown below was also taken on an Amazon EC2 t3a.xlarge machine with 4 CPUs and 16GB RAM of memory, and made by qperf. The only difference here is the unit of measure, which is in milliseconds, because it contains latency value differences. The setups were the same, and we deducted Canal values from Cilium, so that if there was a positive value in a red cell, Cilium had a higher latency in that particular setup, with its message size. If, however, there was a negative value in a blue cell, Canal had higher latency. As you can see, Canal had higher latency in literally every case. This also applies conversely; higher latency means worse performance, which means that Cilium is the absolute winner here. ![Canal and Cilium latency difference ](/static/image3-network-benchmark-wip-blogpost.png) #### **Kubernetes control-plane and cluster communication** Kubemratic Kubernetes Platform has an architecture in which the control-plane components reside on a different cluster from the workloads. We call this the master cluster, and all workloads present on the so-called user cluster. That’s why it’s important to handle these separately when it comes to internal cluster communication. We benchmarked control-plane cluster communication to estimate the throughputs and latencies between APIserver and the nodes. Both OpenVPN and Konnectivity were benchmarked, and the results can be seen in the table below. ![Benchmarked OpenVPN and Konnectivity ](/static/screenshot-2022-03-24-at-12.53.05.png) Konnectivity had slightly better latencies, but much higher throughput than OpenVPN. Konnectivity is clearly a better tool, based on these two parameters. ## What Is the Optimal Kubermatic Setup? Firstly let’s go back to the pods’ creation time. Based on this experiment, we’ve seen that the more pods you want to occur quickly, the more nodes you’ll need in your cluster. Cilium performed a bit worse in possible throughput when smaller messages were being transported, but won out when it came to bigger message sizes. Considering that Cilium was the absolute winner of the latency contest, it can be a better choice than Canal, especially when bigger messages need to be transported. In the end, Konnectivity appears to be the undisputed champion of the control-plane and cluster communication tools, so using Konnectivity and Cilium in your cluster is a great combination. Just keep in mind that when choosing the tools for your cluster, other parameters besides the ones we measured may also be relevant in your environment. [Contact us](https://www.kubermatic.com/contact-us/) to help you create high performance Kubernetes clusters for your enterprise with our powerful Kubermatic Kubernetes Platform. ## **Learn More** * Video: [See Cilium CNI and other cool features in action](https://www.kubermatic.com/resources/kubermatic-kubernetes-platform-kkp-2-19-highlights/) * Get Started With KKP Easily: [start.kubernetes](/demo/) * Check out KKP’s huge [Technology Integrations](https://www.kubermatic.com/why-kubermatic/#integrations) --- ## Kubermatic Kubernetes Platform 2.20 Is GA! - **URL:** https://www.kubermatic.com/blog/kubermatic-kubernetes-platform-2-20-is-ga/ - **Date:** 2026-05-07 - **Description:** The Kubermatic Kubernetes Platform 2.20 release automates CRD migration to a new domain and adds support for Nutanix HCI. - **Categories:** Products - **Tags:** KKP - **Authors:** Mita Bhattacharya It is with great excitement that we announce general availability of Kubermatic Kubernetes Platform (KKP) 2.20. With this release, we make KKP more robust by improving naming conventions and further strengthening code quality. Due to a policy change, we needed to migrate our CustomResourceDefinitions (CRDs) to new domains. As a result, **this release brings about breaking changes** so please read this post carefully before upgrading to KKP 2.20. But no worries: We got you covered with a **completely automated migration process**. Additionally, we are excited to add **Nutanix HCI** to our list of out-of-the-box providers! ## **Improving KKP Resilience With Automated CRD Migration to New Domain** (CE and EE) The Kubermatic Kubernetes Platform (KKP) uses CustomResourceDefinitions (CRDs) to store information about clusters, users, projects, SSH keys, data centers, etc. in Kubernetes. Every CRD has a unique global name, like a domain name. For example: “Clusters” is “clusters.kubermatic.k8s.io” “Users” is “users.kubermatic.k8s.io” As per [Kubernetes 1.16](https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/2337-k8s.io-group-protection), the \*.k8s.io or \*kubernetes.io groups are owned by the Kubernetes community so we cannot use them anymore. Thus, KKP 2.20 is moving its CRDs to a new domain name: **clusters.kubermatic.k8s.io** will become **clusters.kubermatic.k8c.io** By themselves, CRDs are just data without any logic or special behavior. Their primary purpose is to provide a mechanism to create, store and expose Kubernetes API objects. The Kubermatic domain **k8c.io** allows us to gain more control and flexibility over custom resources. To accomplish this migration, **every resource in every KKP setup needs to be recreated one by one**. But we've got you covered—**this migration is fully automated!** During this process, KKP will be refreshed completely on the management layer, meaning API and control plane will restart. We estimate this to last for less than 2 hours.  User clusters will have a short outage and users have the choice to select how fast or safe they would like to make this outage. **Make sure to check out the documentation and our recommendations to handle this user cluster outage**. Workload changes will be hindered during this period. This update sets the stage for future improvements, including but not limited to a new API, refined roles and permissions, greater admin granularity, extended edge zones and much more! **IMPORTANT:** The steps to migrate from KKP 2.19 to KKP 2.20 have been clearly illustrated [here](https://docs.kubermatic.com/kubermatic/main/tutorials-howtos/upgrading/upgrade-from-2.19-to-2.20/).  The general migration procedure is as follows: * Shutdown KKP controllers/dashboard/API * Create duplicates of all KKP resources in the new API groups * Adjust the owner references in the new resources * Remove finalizers and owner references from old objects * Delete old objects * Deploy new KKP 2.20 Operator * The operator will reconcile and restart the remaining KKP controllers, dashboard and API ## **Boost Your Performance With Nutanix HCI & KKP** (CE and EE) In KKP 2.19, we introduced alpha support for Nutanix HCI. We are delighted to announce that KKP 2.20 now fully supports Nutanix HCI! Nutanix and KKP are a perfect match for on-premise workloads. The hyperconverged infrastructure and state of the art software of Nutanix is perfectly suited to handle container workloads in hybrid scenarios with KKP. Nutanix enables you to deploy containers or virtualized applications at scale without sacrificing performance, availability or security—all from one platform that integrates compute, storage and networking with open source technology. ![Nutanix Provider on Kubermatic Kubernetes Platform (KKP) Dashboard](/static/kkp2.20-nutanix-provider-on-kubermatic-kubernetes-platform-kkp-dashboard-.png) ## **Improved User Experience With the KKP Dashboard** (CE and EE) As always, our aim remains to improve the usability of KKP and your Kubernetes experience. Users will enjoy significant improvements in the dashboard with KKP 2.20. * Redesigned cluster summary for greater clarity ![Cluster Summary KKP Dashboard](/static/kkp2.20-cluster-summary-kkp-dashboard.png) * Redesigned error notification to highlight errors that require immediate attention ![New error notification](/static/kkp2.20-new-error-notification.png) * We have added a new tab in the KKP admin panel for managing rule groups ![Manage rule groups in KKP Dashboard](/static/kkp2.20-manage-rule-groups-in-kkp-dashboard.png) * We have added the option to get Kubeconfig for external (EKS, GKE & AKS) clusters directly from the UI We hope you like and enjoy the new capabilities that our new release offers. As always, we are very interested in your feedback on your KKP experience. You can reach us via [Github](https://github.com/kubermatic/), {{< slackjoinlink "Slack" >}}, or [lots of other ways](https://www.kubermatic.com/company/community/#discussions). ## **Learn More** * Check out the entire [Changelog](https://github.com/kubermatic/kubermatic/blob/master/CHANGELOG.md) * Watch a KKP [product walkthrough](https://youtu.be/a-x-a8a8AcY)  * Dig into our [documentation](https://docs.kubermatic.com/) --- ## Get the Best of Both Worlds With the KKP 2.19 CNI Strategy - **URL:** https://www.kubermatic.com/blog/get-the-best-of-both-worlds-with-the-kkp-2-19-cni-strategy/ - **Date:** 2026-05-07 - **Description:** Find out how you can expect greater control and flexibility by selecting a CNI plugin with KKP 2.19. - **Categories:** Products, Best Practices - **Tags:** KKP, Kubernetes - **Authors:** Mita Bhattacharya ## **Introduction** Kubernetes is all about sharing machines between applications. Typically, sharing machines requires ensuring that two applications don’t try to use the same ports. Managing port allocation across multiple developers is difficult at scale, and exposes users to cluster-level issues they can’t control. Instead of dealing with dynamic port allocation (which introduces a lot of complexity to the system), Kubernetes uses a different, more practical approach: the [Kubernetes Network Model.](https://kubernetes.io/docs/concepts/services-networking/) Since the requirements for this vary depending on the application, Kubernetes abstracts the networking, so that vendors can tailor solutions to different needs and users can choose their preferred networking solution when building their clusters. This is where CNI plugins can help! ## What Is a CNI, and Why Use It? To define a standardized interface between container execution and the network layer, the **Container Network Interface** (CNI) defines the standard between container execution and the network layer. It’s a standard designed to make it easy to configure networking when containers are created or destroyed. The specification’s simplicity has led to its widespread adoption with a large number of supported plugins. Each plugin that conforms to the CNI specification aims to address different aspects of container networking; determining the right plugin, or combinations thereof, therefore, is crucial to meeting project requirements. ## Which CNI Plugins Were Previously Supported by Kubermatic Kubernetes Platform (KKP)? The **Flannel** plugin is one of the oldest and most mature CNI plugins for Kubernetes. It’s a great entry-level plugin that provides access to basic networking features. Best of all, it requires a limited amount of administration to set up and maintain. Flannel, however, lacks advanced features like the ability to configure network policies and firewalls, making it less appropriate for advanced networking applications. **Calico**, on the other hand, has earned a reputation for being reliable, flexible and can support highly performing networks for Kubernetes clusters. With its advanced policy support, it also pairs well with other systems like Flannel. With KKP, we aimed to simplify the process of choosing the right plugin without taking away the user’s control. That’s why we chose to go with **Canal** -> a combination of Flannel and Calico. Canal’s networking layer is the simple overlay provided by Flannel. Layering this on top enhances the base network and Calico’s powerful networking rule evaluation provides additional security & control. Canal is an excellent way for teams to experiment and gain experience before they are ready to test changing their existing networking. ## And, What’s New With KKP 2.19? While we wanted to continue making it as easy as possible for our users to select the right CNI plugin, we also wanted to provide them with greater flexibility. We achieved this in two ways: **1.** **KKP users can select between Canal and Cilium as the default CNI Plugin** **Cilium** is an eBPF (Extended Berkeley Packet Filter) based open-source software deploying, securing, and observing network connectivity between container workloads. Cilium’s ability to apply policies to multiple layers allows greater flexibility to manage traffic ingress and egress within your Kubernetes cluster. Cilium not only makes it simple/easy/painless to apply security policies in a highly dynamic environment by decoupling security from addressing, but can also provide stronger security isolation. We tested the performance of both Canal and Cilium. Cilium performed up to 30% better than Canal when running in ordinary Kubernetes clusters on the same hardware. ![Canal test performance results](/static/canal-test-performance-results-blog-post.png) ![Cilium test performance results](/static/cilium-test-performance-results-blog-post.png) Cilium also has a built-in network observability tool called **Hubble**. Hubble enables deep visibility into the communication and behavior of services and the networking infrastructure in a completely transparent way. ![Network Observability with Hubble](/static/network-observability-with-hubble-blog-post.png) **2.** **KKP users can also “bring your own” CNI plugin** KKP 2.19 supports the CNI type “none” in special cases where the built-in CNIs (Canal and Cilium) may not be sufficient. By selecting “none”, KKP ensures that no CNI is installed in the user cluster and CNI set up and management is entirely up to the user. ![Network Configuration with Kubermatic Kubernetes Platform](/static/network-configuration-with-kubermatic-kubernetes-platform-blog-post.png) ## **In a Nutshell…** KKP users can now choose from the following options: * KKP V2.19 supports two CNI add-ons: Canal and Cilium, and also allows the user to bring their own CNI if desired. * Both Canal and Cilium can be made default add-ons at the same time. One of them will be installed into the user cluster based on the selection. * KKP V2.19 now supports CNI type “none” for special cases. So KKP users can either choose one of the CNI plugins that Kubermatic supports or add and manage a CNI of their choice. This gives full control and flexibility to the users to install any other CNI they might need, regardless of whether it’s supported by KKP or not. ## **Learn More** * Video: [Top 5 features of KKP 2.19](https://www.kubermatic.com/resources/kubermatic-kubernetes-platform-kkp-2-19-highlights/) * Blog Post: [KKP 2.19: What’s new?](https://www.kubermatic.com/blog/kubermatic-kubernetes-platform-2-19-is-ga/) * Get Started With KKP Easily: [start.kubermatic](/demo/) --- ## 100% Uptime With Only 5 hrs of Maintenance Per Month - **URL:** https://www.kubermatic.com/customers/cube-bikes/ - **Date:** 2026-06-23 - **Description:** Find out how CUBE Bikes built a highly available Kubernetes infrastructure with the help of Kubermatic's Managed Services. # CUBE Bikes Gets to 100% Uptime With Only 5 hrs of Maintenance p.m. ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ![Mountain Bike](/static/cube-bike-customer-success-story_background-image_hu_231c5de49cc0945c.png) ![CUBE Bikes Logo](/static/cube_white.png) ## The Challenge ### Release More Often at Less Risk To keep up with their dynamic business landscape, CUBE Bikes’ IT team wanted to increase the frequency of new releases for their business-critical services. They also needed a more automated, dynamic process for updates anytime, so they would no longer need to run these afterhours. In addition, they sought to eliminate unforeseen errors due to interdependencies between services. Essentially, what they needed was high availability of services 24/7/365. ## The Solution ### Build a Highly Available Kubernetes Infrastructure Well aware that containers would help them achieve high availability of their services, the CUBE Bikes’ team chose Kubermatic Kubernetes Platform (KKP) to deploy and manage Kubernetes on their premises. To ensure smooth implementation and ongoing support, they also decided to go for Kubermatic’s Managed Service. After the deployment of KKP was completed within a short delay, they migrated their services one after another to their new highly available infrastructure. ## The Impact ### More Releases, No Day 2 and Day 3 Problems CUBE Bike’s IT team now delivers more releases and updates automatically, without the need for over- night staffing. They’ve eliminated errors due to interdependencies and, according to Helmut Joost, Technological Head of IT, “the whole environment is much more flexible, faster, very stable and easy to scale.” This new world has encouraged Helmut to plan the migration of the remaining legacy services for better functionality and to provide all of the benefits of containerization throughout the organization. ## CUBE Bikes Originally founded in 1993 by Marcus Puerner in a small corner of his father’s furniture factory, CUBE Bikes has grown from importing a small number of bikes to sell in the local area to a global front runner with over 1,000 employees. CUBE Bikes produces 4,000 bikes and e-bikes daily and distributes 400 models in 67 countries worldwide. Their product portfolio includes a broad range of bikes and e-bikes, as well as an extensive collection of clothing and accessories. ![Icon 100% uptime](/images/icons/Icon_100%25-uptime.PNG) ### 100% uptime ![Icon Clock](/static/Icon_clock_cube-bike.PNG) ### Only 5 hours of maintenance per month ![Double quotes image](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==) Working with Kubermatic and the Kubermatic Kubernetes Platform has helped us kickstart the cloud native journey and make optimum use of our existing hardware. Helmut Joost, Software Engineer at CUBE Bikes ![](/) [Read the Full Story](https://f.hubspotusercontent40.net/hubfs/4550048/Marketing/Customer%20Success%20Story_Managed%20KKP_CUBE%20Bike.pdf) --- ## Joining Forces With SVA Software, Inc. - **URL:** https://www.kubermatic.com/blog/joining-forces-with-sva-software-inc/ - **Date:** 2026-05-07 - **Description:** SVA Software, Inc. and Kubermatic announce strategic partnership to jointly bring Kubernetes automation to North America. - **Categories:** Company - **Tags:** Announcements - **Authors:** Kristin Wittig Today, we are excited to announce a strategic partnership with SVA Software, Inc. — the US-based subsidiary of SVA System Vertrieb Alexander GmbH; Germany’s largest privately owned systems integrator in the fields of Datacenter Infrastructure and largest IBM business partner in Europe. From our experience on joint projects in Central Europe, we see that many organizations struggle with building and operating today’s highly distributed and complex IT infrastructures. By leveraging SVA’s superior services and project know-how together with Kubermatic’s well established Kubernetes automation portfolio, we deliver optimum state-of-the-art solutions to customers’ data centers and cloud infrastructure. Partnering with SVA Software, Inc., we are delighted to expand this successful partnership to North America and help businesses empower their infrastructure. We are currently advancing our global business and the partnership is clearly an essential milestone on this path. ## **What Benefits Will the Partnership Bring to Our Customers?** * **Benefit from our tailored solutions:** SVA brings more than 25 years of experience in IT infrastructure to the table. Together with our in-depth Kubernetes expertise, we make sure our projects and solutions are tailored to each customer’s specific business needs. * **Have industry experts on your side:** SVA Software, Inc. and SVA have a combined team of over 400 engineers, so customers benefit from around the clock service. * **Rely on strong partnerships:** This partnership represents our continued commitment to deliver optimum solutions to our customers, by offering a wide range of advisory, implementation, managed and technical services together with other industry-leading vendors.  ## **About SVA Software, Inc.** SVA Software, Inc. is a 100% subsidiary of [SVA System Vertrieb Alexander GmbH](https://www.svasoftware.com/), a German company. SVA Software, Inc. was founded in 2016 selling SVA GmbH developed solutions combined with value added services. SVA System Vertrieb Alexander GmbH is the largest privately owned system integrator in Germany in the fields of Datacenter Infrastructure and is the largest IBM business partner in Europe. The company was founded in 1997 in Wiesbaden, Germany. SVA GmbH now employs more than 2,200 employees at 25 branch offices throughout Germany with a revenue of more than $1.3 Billion (2021) servicing over 3,000 customers worldwide. ## **Where to Learn More** * [About SVA Software Inc](https://www.svasoftware.com/) * [How to Become a Partner at Kubermatic](https://www.kubermatic.com/partners/) --- ## Spin Up Your Kubernetes Infrastructure the GitOps Way - **URL:** https://www.kubermatic.com/resources/spin-up-your-kubernetes-infrastructure-the-gitops-way/ - **Date:** 2024-08-14 - **Description:** Learn more about how to use GitOps principles for declaratively managing your infrastructure. # Spin Up Your Kubernetes Infrastructure the GitOps Way ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Bootstrap your Kubernetes GitOps Toolchain within a few minutes! Here comes our super special sneak-preview of start.kubermatic! Let’s grab the GitOps principles for all levels of your ecosystem – not only for managing your application workload but use it for declaratively managing your cloud infrastructure as well. In this presentation, we cover how we are using GitOps principles to deliver Kubermatic Kubernetes Platform (KKP) with a simple wizard. To get the best possible experience for our users, we combine various cloud native projects including Flux, Helm, Grafana and Prometheus to create an end-to-end toolchain from the choice of the Git provider all the way down to the detailed configuration of the whole stack and KKP resources. On top of that, we dive into secret management (not just for Secret objects) as it’s a critical part of the picture. Zero manual steps, just \`git commit\` and \`git push\`. P.S.: There’s a lot more magic coming up soon…stay tuned;) **Michal Vančo & Daniel Kraus, Kubernetes Cloud Architects at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Azure Resource Optimization - **URL:** https://www.kubermatic.com/blog/azure-resource-optimization/ - **Date:** 2026-05-07 - **Description:** An investigation at a multi-billion chemical giant running KKP to find out if the resource allocation for various pods was legitimate. - **Categories:** Products, Best Practices - **Tags:** KKP, Kubernetes - **Authors:** Csenger Szabo ## **Introduction** Ever since it became more than an atmospheric mass of condensed water vapor, cloud has provided apps the ability to automatically scale with it and significantly impact its use. Cloud enables teams to operate applications without having to constantly and manually modify the underlying resources to fit the actual demand. It also provides cost-effectiveness, because you don’t have to oversize architectures in order to serve occasionally occurring, extraordinarily high use. Or does it? Indeed, if you happen to let go of the reins, your cloud provider could consume a lot more than they should, or than they can, in order for them to run the apps on it. It’s worth checking from time to time what kind of processes you have set up and how they consume your resources, because automated scaling can allocate unnecessary resources, or there could be unnecessary stuff running on them. We did an investigation, for example, at one of our biggest customers, a multi-billion euro chemical giant running Kubermatic Kubernetes Platform (KKP), to find out if the resource allocation for various pods was legitimate. ## **Pod Resource Requests Versus Actual Usage** The main concern that initiated this investigation was that it seemed like we were provisioning more worker node machines in Microsoft Azure seeding without them being used a lot by the user clusters. We wanted to find out what caused this gap. The basic method of scaling works with the help of a service called cluster-autoscaler, which is responsible for scaling up the nodes and the pods. Fundamentally, appropriate resource requests (when more memory or CPU is needed) should precede starting up any pending pods, and pods remain pending when they can’t get the requested resources they need to get set up and to run. Autoscaler automatically creates new nodes if the sum of the pod resource requests is higher than the existing resources. The problem occurs when these requests are much higher than the actual usage. Then unnecessary nodes start to run and this automatically increases the cost of the cloud service. ## **Investigating Legitimate Usage of Resource Types** Key points to investigate: 1. Check if memory usage is in line with memory requests 2. Check if CPU usage is in line with CPU requests 3. Check on volumes utilization 4. Double check VM types being used and which others are available When comparing usage versus requests it’s important to determine how we quantify usage, because it is not a constant value like request is. It has peaks and valleys, so you definitely don’t want to make any architectural changes based on current values. During this investigation we used the resource usage for all types based on an average value over 7 days. ## Check if Memory Usage Is in Line With Memory Requests First of all, we laid down constraints where the proportion of requests versus usage could be considered as healthy. In this case, greater than 512 MB of requests by the pods and less than 25% of usage. ![Memory utilisation and memory requests commitment](/static/memory-utilisation-and-memory-requests-commitment.png) As we can see, the memory requests are pretty much in line with the actual usage, which seems quite healthy. ![Memory Usage Table](/static/azure-resource-optimization_namespace-pod-table_reworked.png) In order to achieve smart optimization, it’s also crucial to know what particular pods are responsible for. For instance, the namespace s3-syncer contains cron jobs which only run for a certain period of time, so we shouldn’t include them for optimization. As memory requests seemed to be in line with utilization, we didn’t change any of them at this point. If you are in a different situation, where this isn’t the case, you’ll need to fine-tune memory usage ([about fine-tuning memory](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)). ## Check if CPU Usage Is in Line With CPU Requests We also laid down constraints where the proportion of requests versus usage could be considered as healthy for this area. In this case it was greater than 250 millicores of requests by the pods and less than 50% of usage. So we looked for higher CPU allocations with relatively low utilization. ![CPU utilisation and CPU requests commitment](/static/cpu-utilisation-and-cpu-requests-commitment.png) You don’t have to be a rocket scientist to see that there’s a large gap between CPU requests and the actual CPU usage. The overflow is almost 3 times. We definitely have to dig deeper and analyze the pods’ CPU requests. ![The pods’ CPU requests table](/static/check-if-cpu-usage-is-in-line-with-cpu-requests-table.png) This table is a dummy version of the original, because it consisted of many pods, so in order to demonstrate and focus on the method specifically, we made it simpler. In our case, the pods highlighted in green had the potential of decreasing ([setting CPU requests](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)) their invalid amount of CPU requests. Canal runs as DaemonSet, so it presents on all nodes necessary for networking. However, we can reduce its CPU core request, which will release 150 millicores of CPU on each machine. Most of the MLA and monitoring pods are also significantly over-requested, so by setting their requests lower we can release 240 millicores on average. In our case we were able to save roughly 5 cores, which is equal to completely freeing up a whole machine. ## **Check on Volumes Utilization** Storage and claimed PersistentVolume usage was checked and the cluster was using 57 out of 64 possible volumes in 8 nodes. This should be considered as high volume usage and it’s beneficial to investigate further. ![Check on volumes utilization table](/static/check-on-volumes-utilization-table.png) We have reached the maximum number of volumes that can be attached to a node in 6 out of 8 machines. Let’s check the number of volumes used by each namespace: ![Checking the number of volumes used by each namespace table](/static/checking-the-number-of-volumes-used-by-each-namespace-table.png) The volumes highlighted in green used by MinIO namespaces can be removed, because they were used for testing. Here it’s important to note again that you have to know what you can get rid of without negative impact on the services. So in this case we were able to free up a total of 5 volumes. When MinIO needs growth, it will need 4 volumes per increase. Every new user-cluster requires 3 volumes. This means that volumes will be driving up the VM count relatively quickly. These VMs don’t have enough storage capacity to serve the cluster and will reach the limit prematurely. ## Double Check VM Types We Use and Others That Are Available Let’s look into the VM types we use in Azure and also consider a more comprehensive one for our architecture. It’s been mentioned that VMs with more storage capacity would be more satisfactory. Let’s compare the current VM type with another in Azure: ![Compare the current VM type with another in Azure table](/static/compare-the-current-vm-type-with-another-in-azure-table.png) DS3 VM nodes come with the same amount of CPU as the currently used D4S. However, since we are about to optimize the CPU usage and decrease it dramatically, we’ll probably be good to go with 5 or even 4 nodes. The amount of memory also decreases with fewer nodes, but we are only utilizing 50-60% of our current memory capacity, so the decreased amount of memory will be quite enough for the cluster. The advantage of DS3 machines is that they have more storage capacity (almost double per node), and even with fewer than 5 nodes, we’ll have a higher amount of volumes attached to our cluster. So it seems that DS3 is a much more efficient choice for our cluster in terms of  CPU, memory and volume. The key takeaway here is to choose your machines with the provided resources that are best suited to your architecture. And optimizing resource consumption is more important than choosing the right machines, because non-optimized consumption could lead you to selecting the wrong type of VMs. As shown, after optimization we were able to reduce our cloud expenses by 25%, so optimizing your VM setup is definitely worth doing. ## **Some Useful Links to Learn More** * Finding the most suitable VM type in [Azure](https://azure.microsoft.com/en-us/pricing/details/virtual-machines/series/) * Read more about [KKP Cluster Scaler](https://www.kubermatic.com/blog/kkp-cluster-autoscaler/) * Learn more about external cluster management and other highlights in [KKP 2.19](https://www.kubermatic.com/resources/kubermatic-kubernetes-platform-kkp-2-19-highlights/) ## **Next Steps** So, now we have an action plan to make our cluster more efficient! However, all of these changes, even changing the machine deployment, should be applied in a sandbox first. Then we want to verify that these changes yield the desired increased efficiency and lower the unnecessary consumption of resources, without causing any instability in the workloads. If the planned changes appear to be working in reality, we can start leveraging the new setup in production! Contact us for cloud optimization [here](https://www.kubermatic.com/contact-us/). --- ## CampusOS: Building Tomorrow’s Open 5G Campus Networks - **URL:** https://www.kubermatic.com/blog/campusos-building-tomorrows-open-5g-campus-networks/ - **Date:** 2022-02-21 - **Description:** Kubermatic brings in its Kubernetes and cloud native expertise to build the ecosystem for tomorrow’s open 5G campus networks. - **Categories:** Company - **Tags:** Announcements - **Authors:** Kristin Wittig To those familiar with containers and Kubernetes, the superiority of these cloud native technologies lie at hand. To all others, the concepts are often too abstract and hard to understand. As a consequence, I will find myself rather frequently shorten long explanations with a simple “we build cool stuff under the hood that helps others build very cool stuff on top”; then enumerating customer projects where our solutions build the basis for easily accessible use cases like [WOBCOM’s Smart City platform](/customers/wobcom/). For this reason, I am very happy that Kubermatic has been selected as a joint partner of CampusOS: a flagship project of the German Federal Ministry of Economics and Climate Protection (BMWK) and coordinated by the Fraunhofer Institute. The goal of this project is to foster 5G and 6G innovation and to advance enterprise applications in areas such as Industry 4.0 and connected mobility. To this end, the 22 industry and research partners of CampsOS collaborate to build a modular ecosystem for open 5G Campus Networks consisting of open radio technologies and interoperable network components. 5G Campus Networks are local and customized private mobile networks that can cover a few hundred square meters to a few square kilometers. This is particularly interesting for the industry segment to optimize their existing business processes and open up entirely new business models. The CampusOS ecosystem will be created as a technology toolbox including a catalog and proposals for different operating models. Using network virtualization supplemented by AI and machine learning, end devices and functionalities of the radio access network (RAN) and core network (CORE) can thus be combined dynamically and individually tailored to form a modular and secure 5G campus network.   Thanks to our proven experience with Kubernetes and edge computing use cases, Kubermatic has been selected to build the Open-RAN-nodes that connect the user with the core network, the cloud, the internets and other users— a central piece of the overall architecture of such networks. Or: cool stuff under the hood that helps others build cool stuff on top.  The CampusOS project will run for 3 years with an overall funding of 18.1 million. We feel very honored to contribute to this ambitious and visionary endeavor and will of course keep you updated on the milestones.. ## **Read More** * Blog Post: [Edge Computing Requires Cloud Native Thinking Today](/blog/edge-computing-requires-cloud-native-thinking-today/) * [Edge Computing With Kubermatic Kubernetes Platform](/solutions/edge-computing/) --- ## Kubernetes Security With the CIS Benchmark and KKP 2.19 - **URL:** https://www.kubermatic.com/blog/improving-kubernetes-security-with-the-cis-benchmark-and-kkp-2-19/ - **Date:** 2026-05-07 - **Description:** Find out how KKP 2.19 enables platform operators to provide a standardized security level and score better results on the CIS Benchmark. - **Categories:** Products, Best Practices - **Tags:** KKP, Kubernetes - **Authors:** Marvin Beckers With Kubernetes becoming an ubiquitous platform for running software at scale, an obvious but sometimes overlooked topic is security. Over the past years, several guidelines to secure Kubernetes clusters have been released. Among them is the [CIS Benchmark for Kubernetes](https://www.cisecurity.org/benchmark/kubernetes?utm_campaign=2022-02_Content%20Marketing_CIS%20Benchmark&utm_source=ppc&utm_content=CIS%20Website), which is being published and is receiving updates since 2017. Kubermatic is committed to deliver a modern and secure Kubernetes platform.  To meet our commitment, we introduced several changes and new features with our open source Kubermatic Kubernetes Platform (KKP) 2.19 that will help platform operators score better results on the CIS Benchmark and subsequently provide a standardized security level to their developers and end users.The CIS Benchmark recommendations can also be automatically validated with various tools. However, those tools make certain assumptions around cluster architecture. So, KKP’s control plane design would mark tests that should be considered “passed” as “failed”. For example, some recommendations in chapter 1 recommend certain file permissions on manifests like kube-apiserver; but KKP does not write those to disk at all, so that recommendation does not apply to KKP. We broadly categorized recommendations made by the benchmark into three categories: * Recommendations affecting running workloads on user clusters. * Optional features that cluster operators can enable and configure to improve their compliance. * Changes to how KKP deploys and runs a Kubernetes cluster. For the first category in specific, we highly recommend downloading the CIS Benchmark and checking out chapter 5, “Policies”. Several recommendations are “soft” and ask cluster operators to “minimize” the usage of security-relevant settings, not eliminate them completely, as that might not be possible. KKP components running on user clusters have been adjusted to follow those recommendations where possible, but we recommend users to review the recommendations carefully and implement them in a way that works for their organization. As an example, [KKP offers integration with Open Policy Agent (OPA)](https://hubs.li/Q014n2vr0) to implement such policies. ## **New Features in KKP 2.19** Iterating on our existing feature set, our 2.19 release adds additional functionality to enable cluster operators to adhere to the CIS Benchmark and other security guidelines in accordance with their requirements more closely. Let’s jump right in with some of the highlights from this release. ### **Audit Logging Presets** While KKP already supported audit logging, the new audit logging preset feature allows cluster operators to select a pre-defined audit policy maintained by KKP developers. The selection will be accessible when enabling audit logging from the cluster creation wizard. A full description of the feature is available [in the KKP documentation](https://hubs.li/Q014n3160), but this feature is built for cluster operators that want to use a solid baseline for Kubernetes API audit logs, placing them in compliance with the CIS benchmark (both “minimal” and “recommended” presets cover CIS benchmark recommendation 3.2.2). It is still possible to define a custom audit policy for those with more specific requirements. ### **EventRateLimit Admission Plugin** KKP 2.19 also saw the addition of support for the [admission plugin EventRateLimit](https://hubs.li/Q014n3hW0). The CIS benchmark recommends to enable this plugin (item 1.2.9). This plugin will allow cluster operators to limit the amount of Kubernetes Events generated from a specific namespace, thus preventing short-term “flooding” of the Kubernetes API server if a component (like a third-party operator) generates too many errors. Because the plugin is still considered alpha by Kubernetes and requires some considerations around which limits are deemed acceptable (since rate-limited events might be dropped), we chose not to enable it by default. It can however be selected from the dropdown list of admission plugins during the cluster creation wizard. The Kubermatic UI will then present additional elements to configure sensible limits for your cluster. It is also [mentioned in our documentation](https://hubs.li/Q014n3KC0). ## **Enhanced Out-of-the-Box Security** The great thing about some security improvements made in KKP 2.19 is that they do not require any user interaction apart from running the KKP upgrade! With 2.19, KKP delivers even better security built into the platform. A couple of examples for that would be: * Explicitly setting the allowed TLS ciphers for communication between Kubernetes components. While Go already provides a limited set of ciphers, the CIS Benchmark recommends an even smaller subset to optimize transport security. KKP follows those recommendations now. * Enabling the **NodeRestriction** admission plugin by default. This plugin limits the ability to modify resources at the Kubernetes API with credentials used by Kubernetes nodes. That way, the ability for an attacker to use a compromised node’s permissions is greatly reduced. * When using **etcd-launcher** for the user cluster etcd rings, peer connections between the etcd instances are automatically upgraded to TLS for enhanced security. This live upgrade requires the enhanced functionality that **etcd-launcher** offers, so without that feature enabled, the upgrade will not happen. * Disabling the profiling endpoint on all Kubernetes components. While this debugging endpoint was not accessible in KKP’s control plane architecture anyway, completely turning it off will prevent any attempts to abuse debugging capabilities. And this list isn’t even exhaustive! In addition to that, we deliver support for recent Kubernetes patch releases, which include a significant amount of CVE fixes. See [the full KKP 2.19.0 changelog](https://hubs.li/Q014n4rR0) if you want to know more about that. ## **How to Increase Security in a Kubernetes Platform** As we have mentioned earlier in this post, there are automation tools available that help with benchmarking your Kubernetes security. Unfortunately, their false positives (and false negatives) made it necessary to verify everything manually to be really sure we delivered the security improvements we wanted to deliver. For us, that meant carefully dissecting the requirements and understanding their impact and applicability to KKP. As pointed out earlier, some of the recommendations simply did not apply to KKP. Our process to incorporate recommendations started with one of those tools called [kube-bench](https://hubs.li/Q014n4-70). After running it, we went over every single recommendation, reviewed the results and how the tool got to that result. Of course, we focused on the failures, but we also had to make sure that succeeding tests were correct. Failing tests were, after comparing the actual result to what we would expect it to be, categorized into three categories: * False positives, so recommendations that KKP actually fulfilled but the automation didn’t recognize correctly. * Not applicable recommendations (because of platform architecture; take the file permission recommendation for control planes as an example. KKP does not write those resources to disk at all, so no file permissions can be set) or recommendations to enable deprecated Kubernetes features (these will be removed in the foreseeable future). * Recommendations that we wanted to implement for KKP 2.19 and beyond. After identifying what recommendations we could implement, we started applying those changes all over the KKP code base. Some changes affected the control plane components spawned in Seed clusters (kube-apiserver, kube-controller-manager, etc), some of them in the way Kubernetes nodes are deployed and configured, some required the addition of new features by amending configuration options to our APIs and user interface. You can see, it was a lot of tiny steps until those recommendations ended up in KKP 2.19. Thankfully, the actual rollout of those security improvements scales very well, powered by the high automation level of KKP. No need to manually connect to control plane nodes, adjust a flag for kube-apiserver, restart it and verify the flag was applied - KKP does it all for you when you upgrade to 2.19! ## **Outlook** While we have significantly increased our coverage of the CIS Benchmark recommendations, we are not done yet and always strive to improve our security stance further. We expect to continue delivering “out of the box” security enhancements that might “fly under the radar”, but we hope to support features like **encryption-at-rest** for data stored in etcd in the future as well. This feature will allow cluster operators to define encryption keys or use a KMS service and rotate keys when they are scheduled for rotation by security policies or have been compromised. In addition, we hope to cover additional security recommendations coming out of the Kubernetes ecosystem in the future as well. ## **Learn More** * Video: [Here Come Our 5 Favourite Features of KKP 2.19](https://hubs.li/Q014n6S30) * Blog Post: [Using Open Policy Agent With Kubermatic Kubernetes Platform](https://hubs.li/Q014n70Y0) * Blog Post: [Kubernetes Security Best Practices](https://www.kubermatic.com/blog/kubernetes-security-best-practices/?utm_campaign=2022-02_Content%20Marketing_CIS%20Blog%20Post&utm_source=Blog%20Post_Kubernetes%20Security%20Best%20Practices) --- ## Meet KubeOne 1.4! - **URL:** https://www.kubermatic.com/blog/meet-kubeone-1-4/ - **Date:** 2026-05-07 - **Description:** The 1.4 release comes with support for Kubernetes 1.23 and Cilium CNI as well as alpha-level support for Nutanix. - **Categories:** Products - **Tags:** KubeOne - **Authors:** Mita Bhattacharya, Marko Mudrinić Today, we are pleased to announce that KubeOne 1.4 is now generally available. KubeOne is our open source cluster lifecycle management tool that automates cluster deployment and management in your preferred on-prem, edge, or cloud environment. The previous release provided our users with a brand new Addons API, managed support for encryption providers, and automated Docker to containerd migration. With this release, we introduce our **new KubeOneCluster API** **version** with many new features that simplify configuration management. Additionally, we have added **support for Kubernetes 1.23 and Cilium CNI** and **facilitated CCM/CSI migration**, among other features. KubeOne 1.4 also provides **alpha-level support for Nutanix**.  Here are the major highlights of this release: ## **Configure your Kubernetes Cluster Like Never Before With KubeOneCluster v1beta2 API** KubeOne 1.4 introduces a new KubeOneCluster API version—v1beta2. The new API version provides many new features and improvements over the v1beta1 API.  We would like to highlight the brand new **ContainerRuntime feature**. It allows you to configure your container runtime in new ways, including configuring registry mirrors, private registries, and much more! This is especially useful if you’re running an offline setup or if you want to avoid the Docker Hub rate limits. In addition to that, you can now configure some of the Kubelet settings, such as container maximum files and file size, and resource reservation. Existing users can migrate to the new API version as easily as running the `kubeone config migrate` command and providing their existing manifest. ## **Greater Control Over Your Hybrid and Edge Deployments With Experimental Support for OSM** To extend the functionality of the [Kubermatic Machine-Controller](https://github.com/kubermatic/machine-controller), Kubermatic Kubernetes Platform (KKP) 2.19 comes with experimental support for the [Operating System Manager](https://github.com/kubermatic/operating-system-manager) (OSM). We have introduced the same in KubeOne 1.4.  ![Operating System Manager (OSM) architecture KubeOne](/static/operating-system-manager-osm-architecture-kubeone.png) OSM is responsible for creating and managing the required configurations for worker nodes in a Kubernetes cluster. It decouples the operating system configurations into dedicated and isolated resources. This provides better modularity and maintenance and is an essential milestone towards fully air-gapped clusters, which are on our roadmap for the next release. Stay tuned! ## **Best-in-class Networking With Cilium CNI and Hubble** Cilium CNI support is one of the community-driven enhancements of this release. Cilium is a CNCF (Cloud Native Computing Foundation) incubating project that provides, secures and observes network connectivity between container workloads in a truly cloud native way. To enhance the Cilium user experience with KubeOne, we also integrated the [Hubble add-on](https://docs.cilium.io/en/v1.11/intro/#intro). With this add-on you can observe your network and security with complete transparency from the Hubble UI. ![ Network Observability with Hubble (KubeOne)](/static/network-observability-with-hubble-kubeone-.png) In addition to the Cilium CNI, users can use Canal, Weave-Net or any other CNI plugin, irrespective of whether it is supported by KubeOne or not. To enable Cilium, users need to add the following to the KubeOneCluster manifest: ``` clusterNetwork:   cni:     cilium:       enableHubble: true ``` ## **Facilitated CCM/CSI Migration & More Improvements to the Cloud Providers Support** We have made a lot of improvements to the cloud provider support in the past few releases. We added support for external cloud controller managers (CCMs), CSI drivers, and support for migrating clusters to external CCM/CSI. KubeOne 1.4 offers even more improvements! External CCM and CSI drivers are now supported for the three public cloud providers AWS, Azure (including AzureDisk and AzureFile CSI drivers), and DigitalOcean. On top of that, the CCM/CSI migration is now supported for Azure clusters running in-tree providers. Finally, starting with this release you can also use CCM/CSI migration in clusters with the static worker nodes. The CSI drivers are now unconditionally deployed on all supported clusters running Kubernetes 1.23 or newer. That means you can enjoy the latest features even if you didn’t migrate to the external CCM. ## **Run Kubernetes 1.23** We are always doing our best to ensure support for the latest Kubernetes releases. With this release we support[ Kubernetes 1.23](https://kubernetes.io/blog/2021/12/07/kubernetes-1-23-release-announcement/), so you can enjoy all of the newest features. The [Compatibility document](https://docs.kubermatic.com/kubeone/v1.4/architecture/compatibility/) includes a list of supported Kubernetes versions for each KubeOne release. We hope the new release of KubeOne helps you deploy and operate your Kubernetes clusters with great ease and flexibility. Of course, we are always happy to learn about your thoughts and feedback on our cloud native projects. Just ping us on our {{< slackjoinlink "Community Slack" >}} or on [Github](https://github.com/kubermatic/kubeone). ## Learn More * Read the entire [Changelog](https://github.com/kubermatic/kubeone/blob/master/CHANGELOG.md) * Find KubeOne on [Github](https://github.com/kubermatic/kubeone) --- ## Here Come Our 5 Favourite Features of KKP 2.19 - **URL:** https://www.kubermatic.com/resources/kubermatic-kubernetes-platform-kkp-2-19-highlights/ - **Date:** 2022-12-01 - **Description:** Kubermatic Kubernetes Platform 2.19 is out and comes with Cilium CNI and Konnektivity support. # Here Come Our 5 Favourite Features of KKP 2.19 ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## See our latest features including external cluster management and Cilium CNI support in action! The 2.19 release of Kubermatic Kubernetes Platform is packed with some good stuff. In less than 10 minutes, Damian walks you through our five favorite new features.  See how easy it is to bring all your clusters under one roof with external cluster management. Check how you gain greater control over your OS in hybrid and edge environments with the Operating System Manager. And find out how Cilium CNI and Konnectivity will help you rock your networking performance. **Speaker:** Damian Marquez, Cloud Solutions Architect ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Kubernetes Cheatsheet for C-Level Executives - **URL:** https://www.kubermatic.com/resources/a-brief-brief-for-c-level-executives-on-kubernetes/ - **Date:** 2024-05-21 - **Description:** In the past few years, Kubernetes has seen an extraordinary rate of adoption in large organizations worldwide. What you need to know as a C-level Executive. # Kubernetes Cheatsheet for C-Level Executives ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Solution Briefs ## Download our brief “brief” to arm yourself for that upcoming (and inevitable) discussion about Kubernetes In 2011, Marc Andreessen famously said “Software is eating the world”. How right he was. Ten years later, we’ve seen every enterprise in every industry turn into a software centric organization, challenged to deliver applications to rival the likes of Amazon, Google, et al. Adapt or die is probably truer than ever before. Because of this, Kubernetes has seen an extraordinary rate of adoption in large organizations worldwide and it’s become a very hot topic with C-level Executives. Download our brief to find out: - What and why you need to know about Kubernetes - How Kubernetes can help your organization thrive in this complex world - What business benefits you will get out of this technology If our form couldn't load correctly – This can have multiple reasons like ad blocker, not accepted cookies, JavaScript deactivated. However, you can still get in touch with us! Simply click on the button below, and you'll be able to submit the form and reach out to us for any inquiries or assistance you need. [Open form](https://share.hsforms.com/17MDKMfY_RUiA89NNhqnDOw2piu8) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Kubermatic Kubernetes Platform 2.19 Is GA! - **URL:** https://www.kubermatic.com/blog/kubermatic-kubernetes-platform-2-19-is-ga/ - **Date:** 2026-05-07 - **Description:** The 2.19 release of Kubermatic Kubernetes Platform introduces external cluster support and enhanced edge and hybrid cloud computing capabilities. - **Categories:** Products - **Tags:** KKP - **Authors:** Mita Bhattacharya It is with great excitement that we announce the latest release of Kubermatic Kubernetes Platform (KKP). The 2.19 release focuses on **enhancing KKP’s edge and hybrid cloud capabilities and networking performance**, enabling you to harness the power of Kubernetes with even greater ease and comfort. Compared to the previous release, this release was especially ambitious—**our development team closed 40.8% more epics!** KKP users can now **manage and upgrade external clusters** directly from the KKP dashboard. Additionally, this release includes support for the **experimental Operating System Manager (OSM)**, designed to pave the way for truely air-gapped environments. Moreover, KKP 2.19 introduces **support for Cilium CNI, Hubble and Konnectivity** for cutting-edge networking and network observability. Lastly, with **alpha support for Nutanix HCI**, you enjoy even more flexibility no matter your preferred providers. Full support for Nutanix and Kubernetes 1.23 will soon be available in a patch release. Read on for these and other key improvements: ## **All Your Clusters Under One Roof With External Cluster Support** (CE and EE) Let's face it, if your organization already runs a few Kubernetes deployments, your team is accessing multiple dashboards to get a status overview. Finally, get rid of this hassle! With KKP 2.19 you can monitor and operate your external clusters right from the KKP dashboard.  Import your existing AKS, EKS and GKE clusters and manage their entire lifecycle including upgrades and replica counts from our intuitive UI. View all cluster details, including status, machine deployments and machine deployment nodes from a single pane of glass. These features are implemented using purely API calls without relying on any sidecars or plugins. ![Importing external clusters with Kubermatic Kubernetes Platform ](/static/importing-external-clusters-with-kubermatic-kubernetes-engine.png) ## **More Control Over Your Hybrid and Edge Deployments With OSM Support (Experimental)** (CE and EE) Air-gapped environments are coming! With edge computing use cases on the rise, so is the need to deploy and operate applications in isolated and remote environments. KKP 2.19 adds experimental support for the [Operating System Manager](https://github.com/kubermatic/operating-system-manager) (OSM) to extend the functionality of the [Kubermatic Machine-Controller](https://github.com/kubermatic/machine-controller). This gives you better control over your OS in hybrid cloud and edge environments.  OSM is responsible for creating and managing the required configurations for worker nodes in a Kubernetes cluster. It decouples the operating system configurations into dedicated and isolated resources. This provides better modularity and maintenance and is an essential milestone towards fully air-gapped clusters, which is on our roadmap for the next release. Stay tuned! ## **Best-in-Class Networking with Cilium Support** (CE and EE) One of the community-driven improvements of this release is the introduction of out-of-the-box [Cilium CNI](https://cilium.io/) support. Cilium is a CNCF incubating project that provides, secures and observes network connectivity between container workloads in a truly cloud native way. To enhance the Cilium user experience with KKP, we also integrated the [Hubble add-on](https://docs.cilium.io/en/v1.11/intro/#what-is-hubble). With this add-on you can observe your network and security with complete transparency from the Hubble UI.  ![Network Observability with Hubble](/static/network-observability-with-hubble.png) With Cilium CNI support, KKP users can now choose between the two most popular CNIs Canal and Cilium or simply add and manage a CNI of their choice; regardless of whether it’s supported by KKP or not. * Both Cilium and Canal can be made default at the same time. Either one will be installed into the user cluster based on your preference.   * Additionally, KKP 2.19 supports CNI type “none” for special cases where the built-in CNIs may not be sufficient. By selecting “none” KKP ensures that no CNI is installed in the user cluster and CNI management is left completely up to the user. ![Network Configuration with Kubermatic Kubernetes Platform ](/static/network-configuration-with-kubermatic-kubernetes-platform.png) ## **Enhanced Control Plane Networking with Konnectivity Support** (CE and EE) To harness the power of Cilium with eBPF, KKP 2.19 comes with added Konnectivity support. It provides a TCP level proxy for the control plane (seed cluster) to worker nodes (user cluster) communication. It is based on the upstream [apiserver-network-proxy project](https://github.com/kubernetes-sigs/apiserver-network-proxy) and replaces the older KKP-specific solution based on OpenVPN and network address translation.  Konnectivity has a higher adoption rate within the Kubernetes ecosystem, and has better performance and greater fault tolerance compared to the previous OpenVPN solution.  ![Performance Improvements with Konnektivity](/static/openvpn-vs-konnectivity.png) When the Konnectivity feature is enabled in KubermaticConfiguration, Konnectivity is preselected when configuring Network Configuration for new clusters. In order to use Cilium with eBPF, this option needs to remain activated. ![KKP Network Configuration](/static/network-configuration-for-konnectivity.png) Existing clusters that are using OpenVPN can be migrated to Konnectivity at any time via the “Edit Cluster” dialog in the KKP UI. ![Update KKP clusters to Konnectivity](/static/edit-cluster-to-migrate-from-openvpn-to-konnectivity-in-kubermatic-kubernetes-platform.png) ## Multiple Backup Locations for Improved Business Continuity As KKP Admin, you can now configure multiple backup destinations from the UI Admin Panel. Users can select daily, weekly, monthly or customized backup options.  We hope you like and enjoy the new capabilities that our new release offers. As always, we are very interested in your feedback on your KKP experience. You can reach us via [Github](https://github.com/kubermatic/), {{< slackjoinlink "Slack" >}}, or [lots of other ways](https://www.kubermatic.com/company/community/#discussions). ## **Learn More** * Check out the [entire Changelog](https://github.com/kubermatic/kubermatic/blob/master/CHANGELOG.md#kubermatic-219) * Watch a KKP [product walkthrough](https://youtu.be/a-x-a8a8AcY)  * Dig into our [documentation](https://docs.kubermatic.com/) --- ## Kubermatic Raises Additional $2.3M Seed Funding - **URL:** https://www.kubermatic.com/blog/kubermatic-raises-additional-2-3m-seed-funding/ - **Date:** 2026-05-07 - **Description:** The additional funding will help us broaden our international customer base and speed up continuous product innovation. - **Categories:** Company - **Tags:** Announcements - **Authors:** Sebastian Scheele, Julian Hansert Today, we are excited to announce that **btov Partners has joined and expanded our Seed Series by $2.3M for a total of $8.3M**. The additional funding continues our accelerated business momentum by helping us broaden our international customer base and speed up our product innovation. btov Partners’ Digital Tech Fund backs B2C and B2B businesses in the fields of AI, SaaS, logistics, digital health and marketplaces—a natural fit for Kubermatic’s cloud automation portfolio.  btov aims to be the **first backer of outstanding European entrepreneurs in non-obvious technologies**. Could anything describe Kubernetes and our approach at Kubermatic better than that? While cloud native technologies are disrupting IT infrastructure, with Gartner predicting that “cloud native adoption will explode to the point where by 2025 over 95% of new digital workloads will be deployed on cloud platforms”, **Kubernetes itself remains a complex technology**—not obvious even to many who are deeply involved in the layer between IT hardware and the next-gen applications that will power our future. Our approach of providing best-of-breed, out-of-the-box tools and the flexibility to select, add, or swap out specific features reflects today's market needs. Moreover, **we are strong proponents of open-source software (OSS)** and believe that open standards and a vibrant developer community are the future of enterprise software. **We are more than happy that our seed investors are united by a strong understanding of both the potential of Kubernetes and cloud native technologies, as well as the OSS market.**  What we find especially thrilling about working with [btov Partners](https://btov.vc/) is their outstanding private investor network, their formidable footprint in Europe, and their long-term orientation and focus on sustainability. We are very thankful for the trust that btov and the lead investor, [Nauta Capital](https://nautacapital.com/), have placed in us in this Seed Round. **We are looking forward to advancing cloud native adoption and serving up the speed, agility, and scalability that enterprises need to build tomorrow’s cutting edge technologies.** --- ## Scaling ML With Kubermatic Kubernetes Platform - **URL:** https://www.kubermatic.com/blog/scaling-ml-with-kubermatic-kubernetes-platform/ - **Date:** 2026-05-07 - **Description:** Learn how to deploy, scale, and manage a Deep Learning Model that serves up image recognition predictions with Kubermatic Kubernetes Platform. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Chaimaa Zyani As enterprises mature in their appreciation and use of AI, machine learning, and deep learning, a critical question arises: How can they scale and industrialize ML development? Many conversations around machine learning focus on the actual model, however, this is only one step along the way to a complete solution. To achieve actual application and scale in production, models must be developed within a repeatable process that accounts for the critical activities that precede and follow model development including finally getting it into a public facing deployment. This post demonstrates how to deploy, scale, and manage a Deep Learning Model that serves up image recognition predictions using [Kubermatic Kubernetes Platform](https://www.kubermatic.com/products/kubermatic-kubernetes-platform/). Kubermatic Kubernetes Platform is a production grade open-source Kubernetes cluster management tool that offers flexibility and automation to integrate with your ML/DL workflows with full cluster lifecycle management. Let’s get to it! ## 1. Making The Model Accessible Using Flask Server We are deploying a Deep Learning model for image recognition. We used the [CIFAR10](https://www.cs.toronto.edu/~kriz/cifar.html) dataset that consists of 60000 32x32 colour images in 10 classes with the [Gluon](https://cv.gluon.ai/) library in [APACHE MXnet](https://mxnet.apache.org/) and NVIDIA GPUs to accelerate the workload. If you would like to use a pretrained model on CIFAR10 dataset check out this [link](https://gluon-cv.mxnet.io/build/examples_classification/demo_cifar10.html). We trained the model over a span of 200 epochs, as long as the validation error kept decreasing slowly without causing the model to overfit. We can better observe the training process though this plot : ![Plot showing deep learning process with CIFAR10 Dataset](/static/plot-showing-deep-learning-process-with-cifar10-dataset.png) One important step after training is to save the model’s parameters so that we can load them later. ```python file_name = "net.params" net.save_parameters(file_name) ``` Once the model is ready, the next step is to wrap your prediction code in a Flask server. This allows the server to accept an image as an argument to its request and return the model’s prediction in the response. ```python from gluoncv.model_zoo import get_model import matplotlib.pyplot as plt from mxnet import gluon, nd, image from mxnet.gluon.data.vision import transforms from gluoncv import utils from PIL import Image import io import flask app = flask.Flask(__name__) @app.route("/predict",methods=["POST"]) def predict(): if flask.request.method == "POST": if flask.request.files.get("img"): img = Image.open(io.BytesIO(flask.request.files["img"].read())) transform_fn = transforms.Compose([ transforms.Resize(32), transforms.CenterCrop(32), transforms.ToTensor(), transforms.Normalize([0.4914, 0.4822, 0.4465], [0.2023, 0.1994, 0.2010])]) img = transform_fn(nd.array(img)) net = get_model('cifar_resnet20_v1', classes=10) net.load_parameters('net.params') pred = net(img.expand_dims(axis=0)) class_names = ['airplane', 'automobile', 'bird', 'cat', 'deer', 'dog', 'frog', 'horse', 'ship', 'truck'] ind = nd.argmax(pred, axis=1).astype('int') prediction = 'The input picture is classified as [%s], with probability %.3f.'% (class_names[ind.asscalar()], nd.softmax(pred)[0][ind].asscalar()) return prediction if __name__ == '__main__': app.run(host='0.0.0.0') ``` ## 2. Dockerizing the Model: In order to deploy our model to Kubernetes, we first need to create a container image with our model. In this section, we will install Docker and create a container image of our model. Here are the steps to follow : * First, download, install, then start Docker ```bash sudo yum install -y yum-utils device-mapper-persistent-data lvm2 sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo sudo yum install docker-ce sudo systemctl start docker ``` * Now let’s create a directory where we can organize our code and dependencies ```bash mkdir kubermatic-dl cd kubermatic-dl ``` * The next step is to create `requirements.txt` file that will contain the packages that the code needs to run ```bash flask gluoncv matplotlib mxnet requests Pillow ``` * Then we create the Dockerfile. This is the file that Docker will read to build and run the model ```bash FROM python:3.6 WORKDIR /app COPY requirements.txt /app RUN pip install -r ./requirements.txt COPY app.py /app CMD ["python", "app.py"] ``` We can break this Dockerfile down into three steps. First, creating the Dockerfile will instruct Docker to download a base image of Python 3. Once completed, we ask Docker to use the Python package manager `pip` to install the packages detailed in `requirements.txt`. Finally, we tell Docker to run our script via `python app.py`. * Once done, we build the Docker container ```bash sudo docker build -t kubermatic-dl:latest . ``` This instructs Docker to build a container for the code located in our current working directory `kubermatic-dl`. * Now that our container is built, we can check that it is working by running the container on our local machine ```bash sudo docker run -d -p 5000:5000 kubermatic-dl ``` * You can check the status of your container by running `sudo docker ps -a` ![Status of Container](/static/status-of-container.png) ## 3. Upload the Model to Docker Hub: Before we can deploy the model on Kubernetes, we first need to make it publicly available. We will do this by adding it to [DockerHub](https://hub.docker.com/). You will need to create a Docker Hub account if you don’t already have one. * Login to your Docker Hub account ```bash sudo docker login ``` * Tagging the image is a way of referring to the image for versioning when we upload it to Docker Hub ```bash sudo docker tag <your image id> <your docker hub id>/<app name> sudo docker push <your docker hub name>/<app-name> ``` ![Uploading Deep Learning Model to Docker Hub](/static/uploading-the-model-to-docker-hub.png) To check your image id, you simply run `sudo docker images` ## 4. Deploy the Model to a Kubernetes Cluster Using Kubermatic Kubernetes Platform: First, we need to create a project on the [Kubermatic Kubernetes Platform](https://www.loodse.com/products/kubermatic-kubernetes-platform/), then we create a Kubernetes cluster. You can find a quick start tutorial [here](https://docs.kubermatic.com/kubermatic/v2.13/tutorials/). ![Creating a Kubernetes Cluster with Kubermatic Kubernetes Platform](/static/ml-bild-2.png) Once the cluster is created, download the `kubeconfig` that is used to configure access to your cluster, change it into the download directory, and export it into your environment. ![Export of Kubernetes Cluster into your environment](/static/ml_bild-1.png) * Using `kubectl`, check the cluster information such as the services which are started on your cluster by `kube-system`: ```bash kubectl cluster-info ``` ![Checking the cluster information](/static/checking-the-cluster-information.png) * Next, to run the container in the cluster, we need to create a deployment (`deployment.yaml`) and apply it to the cluster. ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: kubermatic-dl-deployment spec: selector: matchLabels: app: kubermatic-dl replicas: 3 template: metadata: labels: app: kubermatic-dl spec: containers: - name: kubermatic-dl image: kubermatic00/kubermatic-dl:latest imagePullPolicy: Always ports: - containerPort: 8080 ``` ```bash kubectl apply -f deployment.yaml ``` * To expose our deployment to the outside world, we need a service object that will create an externally reachable IP for our container. ```bash kubectl expose deployment kubermatic-dl-deployment --type=LoadBalancer --port 80 --target-port 5000 ``` * We’re almost there! We finally need to check our services in order to determine the status of our deployment and get the IP to call our image recognition API ```bash kubectl get service ``` ![Check the services in order to determine the status of our deployment](/static/check-services-in-order-to-determine-the-status-of-our-deployment.png) * To test our API we can use these two images using the external-ip ![Picture of a horse and a dog](/static/picture-of-a-horse-and-a-dog.png) ![Test API: Input picture is classified](/static/test-api_input-picture-is-classified.png) **It’s Aliiiiive!** ## Summary In this tutorial, we created a deep learning model to be served as a REST API using Flask. We then put the application inside of a Docker container, uploaded the container to Docker Hub, and deployed it with Kubernetes. With just a few commands [Kubermatic Kubernetes Platform](https://www.kubermatic.com/products/kubermatic-kubernetes-platform/) deployed our app and exposed it to the world. --- ## Multi-cloud: The Good, the Bad and the Ugly - **URL:** https://www.kubermatic.com/blog/multi-cloud-the-good-the-bad-and-the-ugly/ - **Date:** 2026-05-07 - **Description:** In this blog post, I’ll highlight the good, the bad, and the ugly about multi-cloud to provide some guidance on how to build your cloud strategy. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Sebastian Scheele “The days of single cloud deployments are gone”, according to David Linthicum, Chief Cloud Strategy Officer at Deloitte and I couldn't agree more: Flexera’s 2021 State of the Cloud Report states that **93% of businesses are already moving to a multi-cloud architecture.** If at first this number seems hard to believe, it’s important to take a step back and understand what multi-cloud actually means: Multi-cloud can consist of either **several public clouds or a hybrid scenario that combines on-premises data centers with one or more public clouds**. The often cited article [“The Cost of Cloud, a Trillion Dollar Paradox”](https://a16z.com/2021/05/27/cost-of-cloud-paradox-market-cap-cloud-lifecycle-scale-growth-repatriation-optimization/) makes a strong case for the latter, arguing that while public clouds enable businesses to optimize for innovation, agility and growth, scaling over a longer period has a cost implication and is often underestimated when growth slows. Take Dropbox, for example, which has reported savings of $75M over two years by repatriating parts of their workloads from public cloud back into their own hardware. This circumstance clearly shows that despite the huge potential of hybrid and multi-cloud, **things are not as easy as they often appear at first glance** and it’s a big mistake to look at your cloud strategy in a one-dimensional and simplistic way. In this blog post I’ll highlight the good, the bad and the ugly, to provide some guidance on how to build your multi-cloud strategy. Let’s take a look at the sunny side of multi-cloud first. ## **The Good: Making the Case for Multi-Cloud** The fact that others are doing it has never been a good reason to act. But in a world where your IT builds the backbone of business operations, multi-cloud yields a lot of must-have benefits including: * **Best of Breed:** Vendors release new updates and services every day and you have to be able to exploit the best of them. Multi-cloud gives you the opportunity to optimize services for specific business requirements. * **Performance:** Organizations can leverage high-speed infrastructure and proximity to maximize application deliverables. This in turn facilitates a better user experience and faster response times, with acceptable cost and performance metrics. * **Resilience:** Data storage resources are subject to outages, increasing many types of business risks. Multi-cloud improves security, offers more failover options and better disaster recovery plans. In addition, issues like latency, packet loss and jitter, which can occur when riding between servers and networks and affect performance, are minimized. Critical applications and data are protected by providing redundancy of your resources in a cloud located away from an affected area, to ensure reliability and security. * **Innovation:** Automation has resulted in a better organization of infrastructure, applications and data, that now exist in multiple cloud environments. By automating multi-cloud management, a wide variety of workloads can be aligned, hybrid workflows can be managed and DevOps can be integrated to deliver business services faster. * **Cost Management:** With multi-cloud you can optimize for cost, thanks to the availability of a variable infrastructure to achieve best use and scale. (However, the Dropbox example demonstrates that cost optimization is not always an easy thing to do). * **Risk Management:** Multi-cloud can help to realize a multi-layered approach to security by including vulnerability testing, API asset consolidation, and strong authentication mechanisms as components of independent, redundant systems, for maximum protection against attack events. ## **The Bad: Nothing Is Perfect** With all of these benefits, the value is huge. But from our experience with our customers, we see that many businesses are facing tremendous challenges that can not only eliminate those benefits, but in the worst case scenario even put business operations at risk. The most common of these that our team is encountering are: * **Expertise:** Efficient management of a multi-cloud environment to ensure high availability and security requires a level of knowledge and skills not available in most organizations. * **Legacy Systems & Security:** Most organizations must maintain some legacy systems due to the nature of their business or industry. Migrating to a multi-cloud scenario and integrating these older systems has potential security risks and requires proper assessment of all architectures to avoid trouble. * **Privacy & Protection:** While storing all data on-prem has its own challenges when it comes to cyber security, implementing a multi-cloud strategy can result in another level of complexity. Certainly, it’s important to make sure that access is seamless, but it’s just as critical to minimize privilege and maximize a strong architecture to support this. Ineffective management presents challenges and limitations that put data privacy and protection at risk. ## The Ugly: Complexity Will Kill You And here it is, the final boss in every multi-cloud deployment: * **Operational Complexity:** Databases, storage systems, compute platforms, security and governance systems…..with multi-cloud the number of entities that you need to deploy, manage and monitor simply explodes. And these will increase exponentially as you grow and continue to scale. It becomes quickly apparent that combining all of these will stretch proper management and control beyond the capabilities of your team, resulting in potentially critical issues. Operational complexity is clearly the #1 challenge to address right from the start. ## **Don’t Shoot Without a Clear Target** Looking at the tremendous impact that not succeeding on your multi-cloud strategy can have, it’s no surprise that the “The Cost of Cloud, a Trillion Dollar Paradox” article concludes that **“the largest opportunity in infrastructure right now is sitting somewhere between cloud hardware and the unoptimized code running on it.”** The truth is that only a central abstraction layer with a high degree of automation can remove the ever increasing operational complexity of multi-cloud environments. And while you want to make sure that such a platform spans all of your environments end-to-end, you also need to protect the existing systems you have in place. A target that clearly requires thorough planning. At Kubermatic, we have always considered multi-cloud as a clear business imperative. That’s why we have designed Kubermatic Kubernetes Platform as the world’s most adaptable and autonomous software delivery platform: KKP makes it easy for you to provide a harmonized abstraction layer with one consistent set of tooling while protecting your existing systems. If you would like to discuss how we can help you build for multi-cloud success in more detail, [feel free to reach out](https://www.kubermatic.com/contact-us/). We are happy to help you conquer the final boss and hit the target. --- ## Building the Digital Backbone for Wolfsburg’s Smart City - **URL:** https://www.kubermatic.com/customers/wobcom/ - **Date:** 2026-06-23 - **Description:** WOBCOM leverages KKP to turn their data center into a high performance cloud platform to deploy and roll out new Smart City services instantly. # WOBCOM Builds the Digital Backbone for Wolfsburg’s Smart City ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ![Smart City](/static/Smart-City-Background-for-WOBCOM-Success-Story_hu_8a7ddb4bbb503abc.jpg) ![WOBCOM logo](/static/WOBCOM_Logo_RGB_Halbnegativ_resized.png) ## The Challenge ### Building Wolfsburg’s Smart City Infrastructure As the internet service provider for the City of Wolfsburg, WOBCOM is responsible to build and manage the infrastructure required to centrally deliver the Smart City services being developed by the #WolfsburgDigital initiative. At the same time, the WOBCOM team wanted to maintain the focus of their own resources on the development of new digital offerings without having to allocate their time and effort on keeping things up and running. ## The Solution ### Migrate to One Centralized, Hands-Off Platform WOBCOM was able to deliver a highly automated centralized platform by leveraging Kubermatic Kubernetes Platform (KKP) to create a true abstraction layer between their VMware vSphere powered data center and their containerized services. By opting for the Managed Service, their team did not have to invest in upfront knowledge building and migrated all of their existing services from zero to production in only three weeks. ## The Impact ### Time to Focus on Value Creation By adding Kubermatic Kubernetes Platform as an abstraction layer, WOBCOM has turned their data center into a high performance cloud platform to deploy and roll out new Smart City services instantly. Thanks to the high adaptability of KKP, WOBCOM easily integrated a customized all flash Pure Storage system that allows them to consume and deliver real-time data in the highly distributed Smart City system. The WOBCOM team was and remains hands-off during and after this deployment, to focus on value creation through new innovative services. ## WOBCOM WOBCOM GmbH is an ISP, based in Wolfsburg, Germany. Since 1996, WOBCOM has been providing internet and telephony services for residential and business customers in Wolfsburg, as well as IP-Transit services at all DC locations. WOBCOM’s data center offers highly robust, secure and monitored colocation services with a backbone of comprehensive national and international connectivity. ![Rocket Icon](/images/icons/rocket.svg) ### 3 Weeks from zero to production ![Double quotes image](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==) The beauty of Kubermatic Kubernetes Platform is that my team can easily test new tooling and just take it out again if it does not deliver what we wanted to achieve. Giovanni Coppa, Head of Data Center and Cloud Innovation at WOBCOM ![Giovanni Coppa](/static/WOBCOM_Giovanni-Coppa_Testimonial_black-and-white_hu_4b5abe59f3320b25.png) [Read the Full Story](https://4550048.fs1.hubspotusercontent-na1.net/hubfs/4550048/Marketing/Customer%20Success%20Story_WOBCOM.pdf) --- ## Why Kubernetes Adoption Needs Management Endorsement - **URL:** https://www.kubermatic.com/resources/why-kubernetes-adoption-needs-management-endorsement/ - **Date:** 2026-03-17 - **Description:** Learn why management endorsement is crucial for Kubernetes adoption and how you can build a cloud native master plan that is designed for success. # Why Kubernetes Adoption Needs Management Endorsement ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Ebook ## Building a Kubernetes master plan that is designed for success In the quest for superior speed, agility, and scalability, businesses around the world are adopting Kubernetes. At the same time, deploying Kubernetes in complex enterprise environments comes with its own set of challenges, so in spite of the technology’s countless success stories, many businesses still shy away. However, if planned properly, this fear is unfounded: If you manage Kubernetes as part of your company’s overall long-term strategy, you’ll be able to make confident decisions and build a master plan that is designed for success. Download our free guide to find out: - Why management endorsement is crucial for Kubernetes adoption - What aspects to consider for an effectively aligned strategy - How to choose the right strategic partner If our form couldn't load correctly – This can have multiple reasons like ad blocker, not accepted cookies, JavaScript deactivated. However, you can still get in touch with us! Simply click on the button below, and you'll be able to submit the form and reach out to us for any inquiries or assistance you need. [Open form](https://share.hsforms.com/1W8L1_zD3TRahICLhyUTsmw2piu8) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Kubermatic News in December 2021 - **URL:** https://www.kubermatic.com/blog/why-hybrid-cloud-is-a-game-changer/ - **Date:** 2026-05-07 - **Description:** Find out how you can save up to €1.2 Million by migrating to a Kubernetes infrastructure. - **Categories:** Company - **Tags:** Announcements - **Authors:** Sebastian Scheele There is no doubt – the cloud has revolutionized the way businesses operate. With **increased scalability, faster deployment times, and improved IT operational efficiency,** migrating to the cloud will give your organization the cutting edge it needs to stay competitive. But the real game changer is its cost-efficiency…there is, however, a catch. Public clouds lower your upfront costs since you only pay for as much as your system requires. Additionally, they have the potential of decreasing your operating costs since you scale only as needed. Yet, when truly optimizing for cost your own custom-built infrastructure might still be the better option for large parts of your workloads: [Dropbox for instance](https://a16z.com/2021/05/27/cost-of-cloud-paradox-market-cap-cloud-lifecycle-scale-growth-repatriation-optimization/?utm_source=hs_email&utm_medium=email&_hsenc=p2ANqtz-9RM2OCiaJLP4JmzKnHve8CD4NEjjYti3yotAupSyIMFGmjEg7ESnz8KS8kk_SjhaC-PQOa) has saved an incredible $75M over two years by repatriating parts of their workloads from the public cloud back into their own facilities. I’m sure that it doesn’t come as a big surprise that simply migrating to the cloud won’t solve all of your problems. So what should your cloud strategy be? It’s pretty simple: If hybrid clouds are the best way to optimize for cost, then **you need to turn your on-premises facilities into high performing cloud native platforms**. Such a transition, however, is complex and not really easy without a well-developed plan. So if you don’t want your cloud costs to go off the rails, you need to develop **a cloud strategy** that combines the best of the public cloud with the best of your existing hardware right from the start. Are you thinking about migrating to the cloud in 2022 and wondering where to start? [Let’s chat](https://www.kubermatic.com/contact-us/?utm_source=hs_email&utm_medium=email&_hsenc=p2ANqtz-9RM2OCiaJLP4JmzKnHve8CD4NEjjYti3yotAupSyIMFGmjEg7ESnz8KS8kk_SjhaC-PQOa)! *P.S.:* Did you know that you can save up to €1.2 Million by migrating to a Kubernetes infrastructure? See for yourself, using our [Kubernetes ROI Calculator](https://www.kubermatic.com/resources/kubernetes-roi/?utm_source=hs_email&utm_medium=email&_hsenc=p2ANqtz-9RM2OCiaJLP4JmzKnHve8CD4NEjjYti3yotAupSyIMFGmjEg7ESnz8KS8kk_SjhaC-PQOa). ![Kubermatic News](/static/kubermatic-news_december-2021.png) ## Kubermatic Raises $6M in Seed Funding to Speed Up Growth & Innovation In November, we announced our **$6M seed funding**, led by Nauta Capital and joined by Bastian Nominacher and Martin Klenk, co-founders of Celonis. We're still overwhelmed by all of the positive responses we received and are extremely excited to work together with these strong partners to build the world’s most adaptable and autonomous software delivery platform. [Read the Full Announcement](https://www.kubermatic.com/blog/kubermatic-raises-6m-in-seed-funding-to-accelerate-growth-automation/) ![Kubermatic Product Updates](/static/kubermatic-product-updates_december-2021.png) ## Multi-User Cluster Monitoring, Logging and Alerting in KKP 2.18 As part of the KKP 2.18 release in September, we introduced **multi-user cluster Monitoring, Logging and Alerting (MLA)** to make operational tasks much easier and way more efficient. Find out how to set up a user cluster MLA stack, how to modify it and what this process looks like in action. [Watch the Video](https://www.kubermatic.com/resources/introducing-multi-user-cluster-mla-in-kubermatic-kubernetes-platform/) ## Automate Your Clusters Across Multi-Cloud with KKP 2.18 Want to explore all of the other fantastic features we introduced with KKP 2.18 and how you can **easily deploy and manage your Kubernetes clusters across any infrastructure with our open source platform**? Check out this product walkthrough with Damian. [See KKP in Action](https://www.kubermatic.com/resources/automate-your-clusters-across-multi-cloud-with-kkp/) ![Kubermatic Blog](/static/kubermatic-blog_december-2021.png) ## Why Kubernetes Management Needs a Seat at the Strategy Table Cloud native is more than just an approach. It’s a combination of technology, culture and processes to ensure the building of future-ready applications with **speed, agility, security, and scalability**. Read on to explore why a cohesive organizational strategy **and** management endorsement are **both** critical to a successful cloud native adoption. [Read Our Blog](https://www.kubermatic.com/blog/why-kubernetes-management-needs-a-seat-at-the-strategy-table/) ![Kubermatic Resources](/static/kubermatic-resources_2021.png) ## A Brief “Brief” for C-level Executives on Kubernetes Kubernetes has seen an extraordinary rate of adoption in large organizations worldwide and it’s become a very hot topic with C-level Executives. If you want to know **why Kubernetes will rule the roost and how it can help your organization thrive in this complex world**, check out our brief “brief” for C-level executives. [Download Our Brief](https://www.kubermatic.com/resources/a-brief-brief-for-c-level-executives-on-kubernetes/) *“Christmas – It's the tenderness of the past, courage for the present, and hope for the future." (Agnes M. Pahro)* ***✨ In the spirit of the season, we wish all of our employees, customers, partners, and the community Merry Christmas and a Happy New Year!✨*** **Happy Holidays!** --- ## Creating Kubernetes Namespaces - **URL:** https://www.kubermatic.com/blog/kubernetes-namespaces/ - **Date:** 2026-05-07 - **Description:** The steps below will guide you on how to create a Namespace and how to create a Kubernetes object in the Namespace. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Seyi Ewegbemi ## Introduction Various Kubernetes objects like Pods, Deployments, Services etc. were created on a Cluster without structuring in previous parts of this series. If you continue this process, these objects will grow exponentially and become challenging to maintain at some point. So, now is a good time to introduce a concept that will mitigate this effect. Kubernetes NAMESPACE is a virtual cluster for organising and structuring Kubernetes objects to ensure smooth operations and project management. ## What Is a Kubernetes Namespace? A Namespace is a Kubernetes object that helps group and structure other Kubernetes objects and partitions them in a Kubernetes cluster. This concept allows you to organize or isolate your Kubernetes resources in a box-like form according to their purpose across multiple users and projects in a cluster. #### Characteristics of Kubernetes Namespaces: * It provides scope for names * It has unique names for resources within but not across namespaces * It does not allow for nesting inside each other * It is used in an environment with many users spread across multiple teams and projects * A Kubernetes object can only be in one Namespace **Question:** In one of the previous exercises, a Pod was created without specifying or declaring a namespace, and yet, there was no error; does this mean the Pod was not created in any namespace? The answer to the question above leads us to the next topic: There are three pre-configured namespaces created by Kubernetes when a cluster is set up, which are: 1. **Default Namespace:** Every namespaced Kubernetes object that is created without specifying a namespace goes to the Namespace defined in your client’s configuration. If none are set, objects go to the default Namespace. So, Kubernetes objects that are namespaced are created in a Namespace which could be either the default Namespace or the one specified by the user. 2. **Kube-System Namespace:** This Namespace is used for system processes like etcd, kube-scheduler, etc. Do not modify or create any objects in this Namespace, as it is not meant for users (to avoid modifying the resources or deleting the components accidentally). 3. **Kube-public Namespace:** This namespace houses publicly accessible data, including a ConfigMap which stores cluster information like the cluster’s public certificate for communicating with the Kubernetes API. ## How to Create a Namespace A Kubernetes Namespace can be created imperatively or declaratively, just like any other Kubernetes objects. You can read more on the imperative and declarative methods of creating Kubernetes objects in [a previous part of this series](https://www.kubermatic.com/blog/kubernetes-as-a-container-orchestration-tool/). The steps below will guide you on how to create a Namespace and how to create a Kubernetes object in the Namespace: ### Option 1: Creating a namespace declaratively The declarative method involves defining a kubernetes namespace YAML file, which is applied using the kubectl command. **Step 1:** Create a yaml file with your desired editor: ```bash $ vim dev-space.yaml ``` **Step 2:** Copy and paste the below configuration into your namespace yaml file: ```yaml apiVersion: v1 kind: Namespace metadata: name: dev ## name of the namespace ``` **Step 3:** Use `kubectl create` command to create the Namespace: ```bash $ kubectl create -f dev-space.yaml namespace/dev created ``` You should see output like `namespace/dev` created, confirming that the namespace was successfully created. ### Option 2: Creating a namespace imperatively Alternatively, you can create a namespace imperatively using the kubectl create namespace command, which allows you to create namespaces directly without using a yaml file. Simply run the following command to create the namespace: ```bash $ kubectl create namespace prod namespace/prod created ## prod is the Namespace name ``` This will immediately create the prod namespace, and the output will confirm the creation: `namespace/prod` created. **Step 4:** After creating namespaces, you can list and check the status of all namespaces with the `kubectl` command: ```bash $ kubectl get namespaces NAME STATUS AGE default Active 16m dev Active 6m23s kube-public Active 16m kube-system Active 16m prod Active 5m50s ``` The output shows all Kubernetes namespaces in your cluster, including three pre-configured Namespaces and the two you just created. **Step 5:** Check the detailed description of the Namespaces with `kubectl describe` command: ```bash Name: dev Labels: <none> Annotations: <none> Status: Active No resource quota. ## More about this further on in this post. No LimitRange resource. ## More about this later on in this post. ------------------------------------------------------------------ Name: prod Labels: <none> Annotations: <none> Status: Active No resource quota. No LimitRange resource. ``` ## How to create Kubernetes Objects in a Namespace Creating an object in a Namespace depends on the method (declarative or imperative) used to create the object. If you create a Kubernetes object imperatively, the Namespace where you want to create the object will be transferred as a parameter together with the command on the command line. In the case of the declarative method, the namespace property with its name will be declared in the manifest YAML file. You can find more details in the example below. **Example 1:** Create a Deployment with two replicas, one in the dev and one in the prod Namespaces: ```bash $ kubectl create deployment my-app --image=redis --replicas=2 -n dev deployment.apps/my-app created ``` or ```bash $ kubectl create deployment my-app --image=redis --replicas=2 --namespace dev deployment.apps/my-app created ``` You can either pass a Namespace property as a flag with `-n` or `--namespace`; they function the same way. Also, `dev` here is the name of the Namespace. **Example 2:** The above object can be created in the dev namespace in declarative form by specifying a Namespace property in the Deployment manifest YAML file. The configuration will look like this: ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: my-app namespace: prod ## where prod is the name of the namespace labels: app: my-app spec: selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: containers: - image: nginx name: nginx-img ``` When you create the Deployment with the `kubectl create` command, it is created in the `prod` Namespace. Now check the Deployments in their respective namespaces: ```bash $ kubectl get pods -n prod # Only the Pods in the prod Namespace will be delivered. NAME READY STATUS RESTARTS AGE my-app-667cdc9ffb-bkrv4 1/1 Running 0 2m32s my-app-667cdc9ffb-mwn9k 1/1 Running 0 2m32s $ kubectl get pods -n dev # Only the Pods in the dev Namespace will be delivered. NAME READY STATUS RESTARTS AGE my-app-667cdc9ffb-lmqvn 1/1 Running 0 2m40s my-app-667cdc9ffb-s7sm5 1/1 Running 0 2m40s ``` ## Connectivity in Namespaces A Kubernetes object can directly access another object in the same Namespace using its name. For example, a Pod can access a Service in the same Namespace using the name of the Service. Also, a Kubernetes object in a Namespace can access the object in another Namespace but not as easily as when both objects are in the same Namespace. A Pod in the prod Namespace can access a Service in the dev Namespace. It will look like this: pod-name.(“service-name.namespace-name.svc.cluster.local”), where **svc** is the **Service** and **cluster.local** is the **domain**. In addition to unrestricted communication between namespaces, networking between them can be locked down using NetworkPolicies. These allow you to define networking rules that can prevent namespace-to-namespace or pod-to-pod communication, if desired. ## Namespaces Resource Quota Each Namespace can be configured to have its own policy on who can modify, create, or edit an object in the namespace. The permission management model behind this is called RBAC (Role-Based Access Control). Individual role assignments allow different teams to use Namespaces in a shared cluster. Resource limits can also be assigned to a Namespace which will control memory and CPU requests and operations. This will add a defined rather than a general level of restriction per Namespace on the cluster. ## Conclusion The significance of Namespace in object demarcation cannot be overemphasised. Moreover, the advantage of having your applications grouped according to teams and departments to guard against cross-departmental errors when accessing the applications on the cluster makes Namespace usage a lot more attractive in Kubernetes. ## Learn More * Read more on [Kubernetes Namespaces here](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) * Learn more about [Kubernetes use-case and insight ](https://kubernetes.io/blog/2016/08/kubernetes-namespaces-use-cases-insights/#:~:text=In%20Kubernetes%2C%20Namespaces%20are%20the,cluster%20into%20multiple%20virtual%20clusters.&text=Each%20user%2C%20team%20of%20users,sole%20user%20of%20the%20cluster.) * You can familiarise yourself more on [Kubernetes Namespaces best ptactices here](https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-organizing-with-namespaces). --- ## Automate Your Clusters Across Multi-Cloud with KKP - **URL:** https://www.kubermatic.com/resources/automate-your-clusters-across-multi-cloud-with-kkp/ - **Date:** 2024-09-26 - **Description:** Find out how to remove the complexity of deploying and managing Kubernetes at scale across hybrid-cloud, multi-cloud, and edge environments with KKP. # Automate Your Clusters Across Multi-Cloud with KKP ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Get a product walkthrough of Kubermatic Kubernetes Platform 2.18 and see its latest features in action! In this demo, we show you how you can easily deploy and manage your Kubernetes clusters across any infrastructure with open source Kubermatic Kubernetes Platform. Also, we present some of our latest features including multi user cluster monitoring, logging and altering and cluster templates.  Kickstart your Kubernetes projects with Kubermatic Kubernetes Platform Community Edition: [Demo](/demo/) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Successful k8s Adoption Needs Management Endorsement - **URL:** https://www.kubermatic.com/blog/why-kubernetes-management-needs-a-seat-at-the-strategy-table/ - **Date:** 2026-05-07 - **Description:** How the interplay of cloud native, containers and Kubernetes will increase the productivity of your workforce - **Categories:** Company, Best Practices - **Tags:** Kubernetes, Announcements - **Authors:** Mita Bhattacharya ## **Introduction** [Organizations](https://www.cncf.io/case-studies/) that successfully implement cloud native technologies often perform better than their peers. Cloud native is not new, but it has certainly gained popularity due to the multitude of success stories that are out there today.  Cloud native, is actually more than just an approach. It’s a combination of technology and processes to ensure the building of future-ready applications with speed, agility, security, and scalability. Those organizations that strategically combine the right elements of technology and processes can bring new ideas to market faster and respond quickly to changing customer demands. Another important factor that often gets neglected is culture. A cultural shift is often underestimated, leading to an incongruent, unsuccessful adoption. Containers are an important aspect of a cloud native strategy because they make cloud-based applications easier to deploy, manage and scale. And yet, according to [this Gartner study](https://www.gartner.com/en/newsroom/press-releases/2020-06-25-gartner-forecasts-strong-revenue-growth-for-global-co), only about 5% of all enterprise applications today are containerized. Why then is container technology not more widely adopted despite its proven benefits? In this blog, we explore how a cohesive organizational strategy and management endorsement are critical to a successful cloud native adoption, and an excellent Kubernetes management partnership will go a long way toward achieving organizational goals. ## **Cloud Native, Containers and Kubernetes Go Hand in Hand** The main benefits of cloud native are: * Faster time to market * Improved reliability of applications * Increased productivity of the workforce * Maximize scalability of platform/applications As mentioned earlier, when it comes to deploying cloud native apps, containers are the best choice. Kubernetes, while not the only option when it comes to container management and orchestration, has become the de-facto standard thanks to its powerful capabilities: 91% of organizations running containers use Kubernetes for orchestration. But implementing Kubernetes does have its own set of challenges. ## **Kubernetes Implementation & Operational Challenges** Developers are familiar with Kubernetes deployment challenges since many organizations face similar ordeals with other IT deployments; data and process integration, security isolation, and underestimating resistance to change to name a few. With Kubernetes, the stakes tend to be higher since it is often at the center of a cloud native journey.  Once organizations have overcome the initial challenges of installation and set up, Day 2 & Day 3 operations come knocking at the door. Common challenges include (but are not limited to) productionizing or monetizing the platform, onboarding users, and managing a multitude  of clusters over their lifecycle. A [study](https://www.devopsdigest.com/organizations-run-into-kubernetes-challenges) by D2iQ found that while 78% of developers and architects claim that Kubernetes add-ons cause a great deal of pain and introduce complexity, only 56% of IT decision-makers echoed a similar sentiment. This insight confirms our experience that decisions are not aligned with execution, resulting in less than efficient Kubernetes deployments. So one of the most important questions for every organization adopting cloud native technologies is: How can we bridge this gap between strategy and execution and what are the important aspects to ensure cohesiveness and success?  ## **Establish a Long Term Vision** Every organization seeks to maintain its competitiveness by growing its market share, minimizing risks, and optimizing costs. A perfect combination of all three is easier said than done. To be successful, an organization must break down its long-term strategy into individual business unit goals, measurable metrics, and regular reviews.  Additionally, retracted economic conditions can shift organizational priorities. With volatile markets, this situation may arise more often now than it did in the past. To be confident about decisions regarding Kubernetes deployment, it must be managed as part of a company’s overarching long-term strategy. ## **Understand & Prioritize Your Long Term Goals** Similar to other organization-wide technology enablements, implementing Kubernetes means prioritizing goals. What percentage of your goals are aligned with accelerated development vs. cost optimization? To understand how Kubernetes will affect your targets, it’s important to understand how it will be used over the next 5 years. Will it require the re-alignment of your teams? Will they need reskilling/upskilling? What’s the best way to communicate these changes? ## **Prepare for a Disruption of Plans** Before Covid-19, not preparing for a "business apocalypse" was unthinkable but manageable, but it’s unforgivable now. Crisis management, social and environmental issues, and rapid technological adoption have absorbed much of the time previously devoted to strategic leadership and financial viability. Moving forward, organizations need to think beyond traditional make-or-buy decisions. It is imperative that any initiative that impacts an organization’s go-to-market plan includes a strategic partner that not only has knowledge about tools and processes but also provides insights tailored to the organization's long-term vision and objectives. ## **Drive Cultural Change** Cloud native is not just an approach, it’s a transformation. It encompasses technology, process, and people in a manner that encourages innovation, scale, and productivity.  Think back to when DevOps first began; at its heart, it increased transparency, communication, and collaboration between previously siloed teams. On a cultural level, it became necessary to encourage continuous learning and continuous improvement. Teams gained greater autonomy through faster, more effective feedback and input.  Kubernetes management requires making cultural shifts on steroids. Teams need to move from a traditional “don’t experiment” mindset to one of “Experiment-Fail Fast-Repeat-Get it Right” as soon as possible. Team leads need to feel confident in taking calculated risks. Digital leaders excel at this mindset adjustment. These cultural changes need to be nurtured as a strategic partnership between the organization and its employees. It’s not just about getting it right, but about getting it right faster than everyone else in a consistent and scalable manner. ## **What Happens If the Misalignment Persists?** When your Kubernetes migration fails, there is a loss of value. How the organization defines value may vary. Some may consider the loss of revenue due to long development cycles, while others may consider a reduced perception as a brand innovator, as a business value. Either way, ultimately it means your customers will look to your competitor when it comes to doing business. ## **Choosing the Right Kubernetes Strategic Partner** Since the deployment of Kubernetes is closely intertwined with business outcomes, it becomes essential to select the right engagement strategy.  Cloud native journeys often begin with organizations taking on this task themselves. But as clusters grow in number and size, managing their growth becomes time-consuming and error-prone.  Our experience is that once you get to about 30, homegrown Kubernetes clusters become unmanageable without automation, due to the amount of time and effort required to maintain them. Other challenges include: * The added complexity of handling a multi-cloud or hybrid strategy and managing multiple vendors * Limited control over consumption, leading to overspending on infrastructure * Restricted identity tracking and loss of flexibility to define user roles, leading to ambiguous work distribution * Problems with governance and compliance checks, resulting in gaping security loopholes As organizations scale their business (which is what cloud native is intended to do), these problems become even more profound. Hence, the need for a strategic partner who not only understands the organization’s goals but can provide the expertise needed for a successful implementation. Any strategic technical roll-out requires a partnership that addresses three pain points or areas of concern: 1. **Identifying Organizational Needs** Every organization is unique, not just in its vision and goals, but also in its architecture. This is sometimes reflected in their IT infrastructure, sometimes not. (Our Kubermatic software, for example, takes into account the needs and challenges of our globally distributed team, which also benefits our customers!) A strong partner would encourage and compel you to deal with reality, rather than viewing the world through rose-coloured glasses. It’s not uncommon to see individual departments that have deployed clusters across multiple clouds. When they can’t manage these on their own, central IT gets involved and discussions generally begin with security and governance. That's a good place to start, but the ultimate goal is to figure out what underlying needs prompted those business units to demand IT involvement. Identifying these needs will lead to a successful Kubernetes adoption and implementation. 2. **Setting up Interconnected Processes and Technologies** The goal of set-up is to provide all of the tools and infrastructure to seamlessly integrate an organization's existing technology landscape while also allowing it to embrace new technologies. While you might not reinvent the wheel, you will improve your existing vehicle with worthwhile new-age accessories. An ideal partner would provide an organization with: * The freedom and benefit of choosing from the entire cloud native space from development to operations * Enterprise-grade security and governance for improved app and workload reliability * Easy, intuitive methods of streamlining authentication, access control, user and team management, and observability * A self-service portal for provisioning and deploying any environment within minutes * Enhance the savings brought about by containerization and Kubernetes in infrastructure and operations After the setup is complete, it’s imperative to verify production readiness and provide the organization with a service plan that meets its needs. 3. **Preparing for Day 2 & Day 3 Operations** While Day 0 (Design) and Day 1 (Deployment) challenges are the most obvious ones when organizations first move to Kubernetes, the longest phase of any application is still production. At this point, the stage and actors are all well-rehearsed and ready, but the production still needs to be closely monitored to avoid any mishaps and to ensure an encore at the end. Another way of looking at this; the lifespan of an application requires a greater investment compared to its design and deployment phases. Having a good Day 2 and 3 strategy can help you save money. So your Kubernetes management partner must provide full lifecycle management along with automated deployments, upgrades, and policy compliance. ## **Final Thoughts** Change, while not easy, is essential. At Kubermatic, our vision is to empower human decision-making through automation. At the end of the day, interaction with a system should be limited to changing workflows purposefully. Anything else has no value. Kubernetes consolidates 20 years of operational experience into software and makes it available to everyone. Market leaders leverage this knowledge to the highest degree and reinvent their application service landscape along with their development workflows. Kubermatic fosters innovation because we free up resources, time, and ultimately cash flow. Our platform unites and harmonizes workflows on infrastructure and container software levels with cloud native principles and cloud native software. Kubernetes is the most powerful tool for running containers, and the Kubermatic Kubernetes Platform makes the most of this tool by optimizing automation to the highest degree. If we’ve sparked your interest, feel free to reach out to us at [sales@kubermatic.com](mailto:sales@kubermatic.com) for a personalized and no strings attached consultation. ## Where to Learn More * [Kubernetes Return-on-Investment (ROI) Calculator](https://www.kubermatic.com/resources/kubernetes-roi/) * [A Brief “Brief” for C-level Executives on Kubernetes](https://www.kubermatic.com/resources/a-brief-brief-for-c-level-executives-on-kubernetes/) * [The Ultimate Checklist for Running Kubernetes in Production](https://www.kubermatic.com/resources/the-ultimate-checklist-for-running-kubernetes-in-production/) --- ## MELLODDY Meets Year Two Objective - **URL:** https://www.kubermatic.com/blog/melloddy-meets-year-two-objective/ - **Date:** 2026-06-10 - **Description:** Find out how MELLODDY has achieved its mid-project objective of demonstrating improved model performance via federated learning enabled collaboration. - **Categories:** Company, Best Practices - **Tags:** Kubernetes, Announcements - **Authors:** Kristin Wittig We are thrilled to announce that the MELLODDY project has met its year two objective of improving the performance of its federated predictive model to accelerate drug discovery. As part of the collaboration between 10 pharmaceutical companies (including AstraZeneca, Bayer & Merck), 5 technology enterprises (including Kubermatic and Owkin) and 2 academic institutions (The Budapest University of Technology and Economics and KU Leuven), Kubermatic has built the scalable Kubernetes infrastructure for this very important endeavour. We are very excited and privileged to be a part of this disruptive Coopetition project, which has already achieved more than 100,000 ML tasks, which represents more than 40,000 tests and demonstrated greater predictive performance of the models used to improve the drug discovery process, which will result in better patient outcomes all over the world. ## **Project MELLODDY – Groundbreaking "Coopetition"** A little over two years ago, Project MELLODDY was launched to harness the potential of artificial intelligence (AI) within the pharmaceutical industry (which already leverages ML internally to mine its data) to expand the deliverables across a larger scale and include competitive sources, while ensuring the privacy of each company’s proprietary information. As the world’s first federated learning (FL) undertaking in drug discovery at this scale, this project has connected major pharma competitors, who have concurrently deployed predictive models that learn from all of the data that has been submitted by each partner, without any exposure to each other’s proprietary information and models. This collaboration will exponentially improve not only the amount of data available, but the efficiencies of collecting and examining its potential, which will dramatically improve drug efficacy, treatment and new development opportunities. ## **How It Works** All partners involved register their proprietary datasets securely in their own local instance of the distributed platform. This allows each individual model to learn from the combined, aggregated knowledge of all of the participants without actually sharing any private data. The secure platform was designed, implemented and is managed by 5 technical and 2 academic partners. BME, Iktos and NVIDIA implemented ML for drug discovery, ensuring privacy and optimizing training speed on NVIDIA GPUs. Kubermatic, Owkin, KU Leuven and Substra Foundation developed and provided the technology for the platform. Owkin provided Owkin Connect, its privacy-preserving framework to enable multitask FL. KU Leuven provided SparseChem, an open-source library for training ML models specific to drug discovery. We deployed Kubermatic KubeOne to build the scalable infrastructure for each pharmaceutical partner. Substra Foundation managed the technical operations, monitored the rollout of the platform, and hosted the Owkin open source code. ## **Year Two** – **Mission Accomplished!** After the consortium had successfully trained a unique predictive model in year one, MELLODDY has now achieved significant improvement of the models, based on the successful completion of a second federated run at scale, using an improved and re-audited platform. Promising observations were also made for the domain of applicability. In-depth analyses will follow to gain a better understanding, though single-partner data and associated neural network complexity are believed to be a factor. The platform enabling this scientific leap guaranteed the privacy and security of the highly proprietary drug discovery data of the 10 pharmaceutical partners on AWS cloud infrastructure spanning the three months of activity, transferring 713,796 GB of data and 912,778 EC2 hours. ## **What’s Next?** Over the next and final year of the MELLODDY project, the consortium will be focussed on achieving a one percent delta improvement for each partner. ## **Where to Learn More** * Visit the [MELLODDY](https://www.melloddy.eu/) website * Blog Post: [Deploy Your Deep Learning Model on Kubernetes](/blog/scaling-ml-with-kubermatic-kubernetes-platform/) * Learn more about [Kubermatic Kubernetes Platform for Machine Learning](/solutions/build-cloud-native-ai-and-ml/) * [Speak with us](/contact-us/) if you want to learn more about our cloud native projects --- ## Introducing Multi-User Cluster MLA in KKP - **URL:** https://www.kubermatic.com/resources/introducing-multi-user-cluster-mla-in-kubermatic-kubernetes-platform/ - **Date:** 2024-03-22 - **Description:** Find out how to set up your own user cluster Monitoring, Logging and Alerting stack in Kubermatic Kubernetes Platform # Watch the webinar and learn more about multi-user cluster MLA! ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Watch the recording and learn how to make operational tasks easier and more efficient for you! It’s unavoidable – you have to know what’s going on in your clusters. Running a Monitoring, Logging and Alerting Stack for each of your user clusters is a painful, manual process. Not anymore! As part of the Kubermatic Kubernetes Platform (KKP) 2.18 release, we introduced multi-user cluster MLA to make operational tasks much easier and way more efficient. In this webinar, we will find out how to set up a user cluster MLA stack and how to modify it. And, of course, we’ll cover the most exciting part: Seeing it in action and how alert integrations work, like, for example, in Slack. **Speaker: Vijay Dharap, Kubernetes Consultant at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Kubermatic Raises $6M in Seed Funding: Speeding Up Growth & Innovation - **URL:** https://www.kubermatic.com/blog/kubermatic-raises-6m-in-seed-funding-to-accelerate-growth-automation/ - **Date:** 2026-05-07 - **Description:** The seed funding will be used to increase open source adoption, broaden the international customer base and accelerate product innovation. - **Categories:** Company - **Tags:** Announcements - **Authors:** Sebastian Scheele, Julian Hansert More than 5 years ago, when Kubernetes was nothing more than a promising technology underdog, we started Kubermatic with barely a handful of people working out of Julian’s living room. Since then we’ve been bootstrapping and growing Kubermatic to more than 80 people worldwide. You can imagine that this was a very educational, challenging and at times bumpy journey. Now we feel that it‘s the ideal time to take the next step and continue our progress, growth and development with strong partners alongside. Today, we’re proud to share some big news and announce that we’ve raised **$6M in seed funding** **to increase open source adoption of Kubermatic Kubernetes Platform, broaden the international customer base, and accelerate product innovation.** The investment round is **led by [Nauta Capital](https://nautacapital.com/)**, one of Europe’s largest B2B-focused Venture Capital firms that invest in early-stage technology companies. In addition, we are excited to have **Bastian Nominacher and Martin Klenk, co-founders of [Celonis](https://www.celonis.com/) as angel investors** on board! (In June this year, Celonis raised $1 Billion at a $11 Billion valuation making the company the most valuable German startup of all time. You can probably imagine how flattered we are by their backing).  When we started our talks with investors, **it was crucial to us that our partners shared our vision of power through automation**. Just like us, Martin Klenk, co-founder and CTO of Celonis, is highly confident that containers and Kubernetes are essential to achieve the flexibility, speed and resilience companies need to scale their business models and modernize their existing IT infrastructure. And just like us, Guillem Sague, Partner at Nauta Capital, is certain that cloud native technologies and open source software will be the dominant drivers to build tomorrow’s zero-touch cloud infrastructure. Our Kubermatic Kubernetes Platform (KKP) provides a complete software solution for teams running containerized workloads across hybrid-cloud, multi-cloud, and edge environments. KKP automates all aspects of operating Kubernetes in highly complex enterprise set-ups while granting flexibility to integrate smart solutions and tools from everywhere.  We’re extremely happy about the trust that’s been placed in us and our mission to build the world’s most adaptable and autonomous software delivery platform and are excited to shape the cloud native future together with our great team, loyal customers and trusted partners, and now with powerful investors at our side.  **Learn More** * Read the [full press release](https://drive.google.com/drive/folders/1o2Y18LLcwzChL_r5Hk3F6Fvq1k85er7l) --- ## OpenStack vs Azure Stack: 5 Key Differences - **URL:** https://www.kubermatic.com/blog/openstack-vs-azure-stack-5-key-differences/ - **Date:** 2026-05-07 - **Description:** This blog post explains the basics of Azure Stack and how it compares to the OpenStack platform. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Sascha Haase If you are seeking to adopt a hybrid-cloud strategy, you might want to evaluate alternatives to OpenStack. Azure Stack is a commercial solution you can use to extend the Azure public cloud to the local data center. It is a common alternative to OpenStack when deploying hybrid clouds. In this article, I explain the basics of Azure Stack and how it compares to the OpenStack platform. (BTW: We stick to our promise to deliver the world’s most adaptable and autonomous software delivery platform. With Kubermatic Kubernetes Platform you can go either way. So completely up to you and your specific use case). ## **What is Microsoft Azure Stack?** [Microsoft Azure Stack](https://azure.microsoft.com/en-us/overview/azure-stack/) is an integrated platform that provides Microsoft Azure public cloud services in a local data center. Organizations can use it to create a hybrid cloud, or for [migrating cloud resources](https://cloud.netapp.com/blog/cloud-migration-strategy-challenges-and-steps) between on-premise and public cloud infrastructure.  Azure Stack provides both platform-as-a-service (PaaS) and infrastructure-as-a-service (IaaS) within an on-premise data center. Azure Stack shares its APIs, management portal, and code with Microsoft Azure to provide a hybrid cloud environment that behaves consistently between on-premises and Azure cloud environments.  That means that developers can consistently create and deploy their applications to either the public Azure cloud or their private cloud. Azure Stack places a range of Azure services on-premises, including Azure App Service, Azure Virtual Machine Scale Sets, and Azure Active Directory for identity management. ## **Azure Stack vs OpenStack: Key Differences** 1. **Architecture** One central difference between the two platforms is the way they build out a private cloud.  Azure Stack takes public cloud computing services and extends them into data centers on-premises. Your organization can run services you would typically run in the public cloud, such as Azure Virtual Machines—using on-premises hardware. Your organization can also use the management and monitoring tools it uses in the public cloud.  OpenStack is not tied to any specific public cloud platform. Rather, it lets organizations run their own cloud services employing OpenStack modules, which provide a wide range of functionality, and components, which provide the core infrastructure functionality for an OpenStack private cloud. 2. **Storage** Azure Stack provides the following storage options: * **Blob storage** — used for [unstructured object data](https://cloudian.com/blog/object-storage-care/). A blob can be any sort of binary or text data, including an image or video file, application files, or documents.  * **Table storage** — suitable for structured datasets, implemented as a NoSQL key-value data store. * **Queue storage** — offers dependable messaging for workflow processing and communication between parts of cloud services. **OpenStack** provides the following storage options: * **Object Storage** — the OpenStack Object Storage service (Swift) provides an Amazon S3-compatible API and a native OpenStack API. It offers resiliency through data replication, and can deal with petabytes of data. * **Block Storage** — the OpenStack Block Storage service (Cinder) offers persistent block storage for compute instances. The Block Storage service manages the complete lifecycle of block storage devices, from the development and attachment of volumes to instances, through to their delivery.   * **Shared File Systems** — the Shared File Systems service (Manila) manages shared file systems in a multi-tenant cloud environment. With the Shared File System service, your organization can create a remote file system, mount the file system on compute instances, and write and read data from the instances to the file system. 3. **Cost** **Azure Stack** charges based on the cloud services used (see this comprehensive [guide to Azure pricing](https://spot.io/resources/azure-pricing-the-complete-guide/)). Typically, these fees are less than what your organization would pay on the Azure cloud, because you are hosting the infrastructure on-premises. But you are still charged for data egress, licensing (for Windows VMs and commercial databases), and other typical cloud costs. This means the total cost of ownership of Azure Stack is likely to be higher than OpenStack. **OpenStack** is an open source platform, meaning it is free to download and use in its original form, and there are no ongoing fees for cloud services. Your organization can opt to deploy OpenStack using a managed solution or commercial distribution, and receive enterprise support. But even so, licensing and ongoing service fees will probably be lower in comparison to Azure Stack.  At the same time, OpenStack is a highly complex ecosystem of open source projects, and an OpenStack project is a major undertaking for any organization. Several developers would have to work for months to set up a large-scale OpenStack deployment. This is in contrast to the Azure Stack solution, which comes fully integrated out of the box. 4. **Hardware Compatibility** **Azure Stack** requires organizations to purchase hardware that is certified for the platform. This severely limits the ability to reuse existing hardware resources, and scale up using commodity hardware. **OpenStack** runs on any hardware, making it easier to build a private cloud with existing infrastructure. Organizations can add new infrastructure to the private cloud on a continual basis, by repurposing existing resources or purchasing new commodity hardware. 5. **Lock-In and Multi-Cloud Support** **Azure Stack** is connected to the Azure public cloud platforms. An organization can easily move workloads from Azure Stack to Azure, but not to other public clouds. This means that effectively, organizations are locked into the Azure cloud. On-premises, Azure Stack has demanding hardware requirements, and in many cases has to be deployed on Microsoft-certified servers. **OpenStack** provides more flexibility on-premises, as it can be deployed on almost all types of on-premises hardware. However, OpenStack is difficult to integrate with public clouds (Azure or otherwise). It does not provide multi-cloud capabilities, so while it does not lock you into a specific public cloud, it also doesn’t make cloud portability easy. ## **Conclusion** In this article I reviewed the key differences between OpenStack and Azure Stack: * **Architecture** - Azure Stack is an extension of Azure’s public cloud infrastructure, while OpenStack is composed of several open source projects. * **Storage** - Azure Stack runs Azure storage services on local resources, while OpenStack uses its own storage solutions - Swift, Cinder and Manila. * **Cost** - Azure Stack charges for its services, even when they are running on local infrastructure, while OpenStack is open source. * **Hardware compatibility** - Azure Stack requires specific, certified hardware while OpenStack can run on any hardware. * **Multi-cloud support** - Azure Stack only supports Azure, while OpenStack can run on any on-premise data center infrastructure. I hope this will be of help as you evaluate Azure Stack as an alternative to OpenStack hybrid cloud deployments. Just let us know [in case you want to discuss](https://www.kubermatic.com/contact-us/) what hybrid or multi-cloud strategy suits you best. --- ## What’s the Status Quo of the Cloud Native Market in Germany? - **URL:** https://www.kubermatic.com/resources/whats-the-status-quo-of-the-cloud-native-market-in-germany/ - **Date:** 2021-11-03 - **Description:** Get all the insights of the ISG study on the development of the cloud native market in Germany and the obstacles that still exist. # What’s the Status Quo of the Cloud Native Market in Germany? ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Business Case ## Download the report of the ISG study to get a comprehensive overview of Germany’s status quo of the cloud native market The [Information Service Group (ISG)](https://isg-one.com/) and [EuroCloud Native (ECN)](https://www.eurocloudnative.de/) initiative were conducting a study to evaluate the status quo of the cloud native market in Germany. As an ECN member, we also had the honor to share our experiences and learnings we made throughout the past few years. The good news is: The concrete understanding of cloud adoption and cloud native technologies has improved a lot in Germany. More than one fifth of the respondents (IT decision-makers from companies with at least 50 employees) are already adopting a cloud strategy and more than 70 percent are planning concretely to adopt soon in order to deliver on innovation, digital transformation and business agility. However, the results also reveal that the lack of sufficient knowledge about  highly scalable cloud native solutions, security concerns and increasing complexity are the main obstacles in the implementation of a cloud strategy. Download the report to get the full insights of the study. If our form couldn't load correctly – This can have multiple reasons like ad blocker, not accepted cookies, JavaScript deactivated. However, you can still get in touch with us! Simply click on the button below, and you'll be able to submit the form and reach out to us for any inquiries or assistance you need. [Open form](https://share.hsforms.com/1gT0zib35S8-z8y3hAMzThw2piu8) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Kubernetes Return-on-Investment (ROI) Calculator - **URL:** https://www.kubermatic.com/resources/kubernetes-roi/ - **Date:** 2023-08-28 - **Description:** Use our Return-on-Investment (ROI) calculator to evaluate the cost savings you realize by migrating your workloads to Kubernetes. # Kubernetes Return-on-Investment (ROI) Calculator ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Business Case ## Get our Return-on-Investment (ROI) Calculator to evaluate your Kubernetes cost savings Moving to Kubernetes has become a business imperative. A successful migration to Kubernetes can have complexities and challenges that need to be overcome. To start building a valid business case for Kubernetes, you need to know what your Return on Investment will be. Our Kubernetes ROI Calculator will help you assess the potential cost savings by migrating your workloads to Kubernetes. Download our Kubernetes ROI Calculator to: - Estimate the cost of your current infrastructure - Calculate the cost of a Kubernetes infrastructure - Increase the magnitude of cost savings by migrating to containers - Quantify operational improvements through automation If our form couldn't load correctly – This can have multiple reasons like ad blocker, not accepted cookies, JavaScript deactivated. However, you can still get in touch with us! Simply click on the button below, and you'll be able to submit the form and reach out to us for any inquiries or assistance you need. [Open form](https://share.hsforms.com/17q5wjHd4TxKiUz6a33HceQ2piu8) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Update Your Kubernetes Policy Management: Kyverno vs. OPA - **URL:** https://www.kubermatic.com/resources/kyverno-vs-opa-update-your-kubernetes-policy-management/ - **Date:** 2022-12-01 - **Description:** Learn more about the pros and cons of two PSP replacement options – Open Policy Agent and Kyverno. # Update Your Kubernetes Policy Management: Kyverno vs. OPA ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Watch the Recording of Our Webinar and Learn More About Kyverno and Open Policy Agent With the latest Kubernetes 1.21 release, pod security policy has been deprecated, leaving many Kubernetes users at risk of being exposed to various exploits. In the meantime, stronger alternatives have emerged in the form of Open Policy Agent and Kyverno. Each of them brings its own strengths and weaknesses. Both of these projects are viable replacements for PSP: They are vastly more capable than simply acting on Pods alone – they are full Kubernetes policy engines. In this recording, you’ll be provided with a comprehensive overview of the pros and cons of Kyverno and OPA. **Mario Fahlandt, Kubernetes Consultant at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Speaking With the Cloud Therapist – Part 2 - **URL:** https://www.kubermatic.com/resources/speaking-with-the-cloud-therapist-part-2/ - **Date:** 2022-12-01 - **Description:** Learn more about the major features of the Kubermatic Kubernetes Platform # Speaking With the Cloud Therapist – Part 2 ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch the Demo and Get Started With Kubermatic Kubernetes Platform This video provides a demo of the Kubermatic Kubernetes Platform (KKP), with Damian Marquez, Senior Solutions Architect at Kubermatic South America. In the video, Damian takes us through all the major features of the KKP, which make managing multiple Kubernetes clusters from different vendors and platforms possible – a movement that has picked up pace in the Kubernetes space, over the past 2 years or so. Damian demonstrates the effortless UI for KKP that can handle multiple activities, including creation of new clusters, cluster management and maintenance, as well as making provisioning containers easy. **Damian Marquez, Senior Solutions Architect at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Speaking With the Cloud Therapist – Part 1 - **URL:** https://www.kubermatic.com/resources/speaking-with-the-cloud-therapist-part-1/ - **Date:** 2022-12-01 - **Description:** Find out how to accelerate your cloud native journey with our open source solutions. # Speaking With the Cloud Therapist – Part 1 ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch the Video and Get a Comprehensive Overview of Kubermatic and Our Solutions In this talk, Kristin Wittig (Head Of Marketing, Kubermatic) provides a quick introduction to Kubermatic, a summary of our solutions and through some success stories, how our solutions help customers to accelerate our cloud plans.  We also looked back at some of the challenges posed by the pandemic and how this has affected customer strategy around Digital Transformation, as well as our own perspective on doing more in the cloud native space. **Kristin Wittig, Head of Marketing & Communications at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## The True State of the Edge - **URL:** https://www.kubermatic.com/resources/the-true-state-of-the-edge/ - **Date:** 2022-12-01 - **Description:** Learn more about recent developments on Edge in various industries. # The True State of the Edge ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Sascha's talk at ContainerDays 2021! Let’s take some time and reflect on the recent developments on Edge in various industries. Time to summarize, debunk myths and paint a picture towards tomorrow that includes approaches by end users and vendors on Edge that are technically feasible, while respecting the cost conundrum. Adaptability comes first! **Sascha Haase, VP Edge at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## start.io: From VHS to Full HD: The GitOps Way - **URL:** https://www.kubermatic.com/resources/start-io-from-vhs-to-full-hd-the-gitops-way/ - **Date:** 2022-12-01 - **Description:** Learn more about how to enhance project velocity from 28.800 minutes of discussions down to 15 minutes of doing - Factor 1920. # start.io: From VHS to Full HD: The GitOps Way ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Sascha's keynote at ContainerDays 2021! Discover how simple applications can enhance project velocity from 28.800 minutes of discussions down to 15 minutes of doing - Factor 1920. Kubermatic proudly presents the next generation of cloud native GitOps, ready to be snatched away by you live. Power through automation! **Sascha Haase, VP Edge at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Kubermatic’s Inception With GitOps - Why Not? - **URL:** https://www.kubermatic.com/resources/kubermatics-inception-with-gitops-why-not/ - **Date:** 2021-10-14 - **Description:** Learn more about how to bootstrap your GitOps Kubernetes toolchain in less than 5 minutes. # Kubermatic’s Inception With GitOps – Why Not? ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Michal's talk at ContainerDays 2021! Let’s grab the GitOps principles for all the levels of your ecosystem - not only for managing your application workload but use it for declaratively managing your infrastructure as well. In this recording, you will learn more about what the use cases for using the GitOps principles for delivering Kubermatic Kubernetes Platform are and how to combine various cloud-native projects to get the best possible experience for the customers. Yes, Michal also covers secret management not just for Secret objects as it’s a critical part of the picture. Zero manual steps, just `git commit` and `git push`… The goal is to make the users happy, let them bootstrap easily, safely store the sensitive data and automate the things on all levels. **Michal Vančo, Kubernetes Consultant at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Goodbye Pod Security Policy – Hello Stronger Alternatives - **URL:** https://www.kubermatic.com/resources/goodbye-pod-security-policy-hello-stronger-alternatives/ - **Date:** 2022-12-01 - **Description:** Kyverno or OPA? Let's make a comparison of two viable replacements for Pod Security Policy. # Goodbye Pod Security Policy – Hello Stronger Alternatives ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Mario's talk at ContainerDays 2021! With the latest Kubernetes 1.21 release, pod security policy has been deprecated, leaving many Kubernetes users at risk of being exposed to various exploits. In the meantime, stronger alternatives have emerged in the form of Open Policy Agent and Kyverno. Each of them brings its own strengths and weaknesses. Both of these projects are viable replacements for PSP: They are vastly more capable than simply acting on Pods alone – they are full Kubernetes policy engines. Let’s have a look together to figure out which one fits your requirements. **Mario Fahlandt, Kubernetes Consultant at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Dockerfile Best Practices: Secure & Efficient Images - **URL:** https://www.kubermatic.com/resources/dockerfile-best-practices-how-to-create-secure-and-efficient-images/ - **Date:** 2024-03-21 - **Description:** Learn more about how to write Dockerfilesto to improve build performance and enhance security. # Dockerfile Best Practices - How to Create Secure and Efficient Images ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Koray's talk at ContainerDays 2021! This talk will provide best practices for writing Dockerfiles to improve build performance, enhance security and reduce final image size. **Koray Oksay, Site Reliability Engineer at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## The 7 Deadly Sins in Kubernetes - **URL:** https://www.kubermatic.com/resources/the-7-deadly-sins-in-kubernetes/ - **Date:** 2024-09-24 - **Description:** This talk will help you understand the pitfalls of not caring about best practices in Kubernetes. # The 7 Deadly Sins in Kubernetes ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Hubert's talk at ContainerDays 2021 Let us jump on that Kubernetes train. It is just another tool for running my apps. Right? … Wrong!!! As Kubernetes becomes mainstream established companies want to benefit from the advantages Kubernetes brings in, too. However, a lot of them underestimate the technical and organizational implications they will face. What happens if you do not care about Resource Requests and Limits? Why do you lose data because of the Shell Form in your Dockerfiles? Why do you have to reconsider how to scale your apps? Why will Kubernetes change your organizational architecture? Why do lots of projects start with one cluster and end up with lots of them? In this recording, you will learn to understand the pitfalls of not caring about best practices in Kubernetes. You will hear war stories about failed migration projects and learn how to be successful with yours. **Hubert Ströbitzer, Kubernetes Consultant at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Annotating Machine Deployment for Autoscaling - **URL:** https://www.kubermatic.com/blog/annotating-machine-deployment-for-autoscaling/ - **Date:** 2026-05-07 - **Description:** Learn about KKP Cluster Autoscaler and how to annotate a desired MachineDeployment for Autoscaling. - **Categories:** Products - **Tags:** KKP - **Authors:** Seyi Ewegbemi ## **Machine Deployment Annotation for Autoscaling** In the last post, we discussed Kubernetes Autoscaler in KKP as well as its usage. We also showed you how to install Kubernetes Autoscaler on a KKP Cluster. Now let’s take it a step further and show you how to annotate the MachineDeployments which you want the Autoscaler to recognize. ## How to Annotate Machine Deployments for Autoscaling? The Cluster Autoscaler only recognizes MachineDeployments with valid annotations. The annotations are used to control the minimum and maximum number of replicas per MachineDeployment. These annotations can also be applied to just MachineDeployments that Cluster Autoscaler should consider, rather than all MachineDeployment objects. See annotation command below: `cluster.k8s.io/cluster-api-autoscaler-node-group-min-size - the minimum number of replicas` (must be greater than zero) `cluster.k8s.io/cluster-api-autoscaler-node-group-max-size - the maximum number of replicas` You can apply the annotations to MachineDeployments once they are created and running by following these steps: **Step 1:** It is assumed that you already have a running KKP Cluster and the MachineDeployments have been created and running. **Step 2:** Run the following `kubectl` command to check the available MachineDeployments on the Cluster: ```bash $ kubectl get machinedeployments -n kube-system NAME AGE DELETED REPLICAS AVAILABLEREPLICAS PROVIDER OS VERSION test-worker-6wjcx 3h56m 2 2 aws ubuntu 1.19.9 test-worker-pndqd 3h59m 1 1 aws ubuntu 1.19.9 ``` **Step 3:** The annotation command will be used with one of the MachineDeployments above to annotate the desired MachineDeployments. In this case, the `test-worker-6wjcx` will be annotated, and the minimum and maximum will be set. **Minimum annotation:** ```bash kubectl annotate machinedeployment -n kube-system test-worker-6wjcx cluster.k8s.io/cluster-api-autoscaler-node-group-min-size="1" machinedeployment.cluster.k8s.io/test-worker-6wjcx annotated ``` **Maximum annotation:** ```bash kubectl annotate machinedeployment -n kube-system test-worker-6wjcx cluster.k8s.io/cluster-api-autoscaler-node-group-max-size="5" machinedeployment.cluster.k8s.io/test-worker-6wjcx annotated ``` **Step 4:** Check the MachineDeployment description. ```yaml $ kubectl describe machinedeployments -n kube-system test-worker-6wjcx Name: test-worker-6wjcx Namespace: kube-system Labels: <none> Annotations: cluster.k8s.io/cluster-api-autoscaler-node-group-max-size: 5 cluster.k8s.io/cluster-api-autoscaler-node-group-min-size: 1 machinedeployment.clusters.k8s.io/revision: 1 API Version: cluster.k8s.io/v1alpha1 Kind: MachineDeployment Metadata: Creation Timestamp: 2021-07-23T11:05:11Z Finalizers: foregroundDeletion Generate Name: test-worker- Generation: 1 Managed Fields: API Version: cluster.k8s.io/v1alpha1 Fields Type: FieldsV1 fieldsV1: F:metadata: …………………… The description details show that the MachineDeployment has been annotated with a minimum of 1 and a maximum of 5. The Autoscaler will only consider the annotated MachineDeployment on the Cluster. ``` **Step 5:** Edit Autoscaler  To edit Autoscaler, click on the three dots in front of the Cluster Autoscaler in the Addons section of the Cluster dashboard and select edit. ![Edit autoscaler image](/static/edit-autoscaler-image-kkp-autoscaler-blog2.png) **Step 6:** Delete Autoscaler You can delete Autoscaler by selecting delete from the drop-down menu, as shown below. ![Delete autoscaler image](/static/delete-autoscaler-image-kkp-autoscaler-blog2.png) Once the delete is confirmed, you can check the Cluster to ensure that the Autoscaler has been deleted using `kubectl get pods -n kube-system` command. The output should be the same as the first. **Summary:** Congratulations! You have successfully annotated your desired Machine Deployment, in order to deploy Autoscaler to optimize your resources, which will likely result in significant cost savings! Please check the “learn more” section below for more resources on Kubernetes Autoscaler and how to annotate MachineDeployment for Autoscaling. ## **Learn More** * Read more about [Kubernetes autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#what-is-cluster-autoscaler) * Learn more about Kubernetes Autoscaler on [Kubernetes official website](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) * You can find more information on KKP Autoscaler in our [official documentation](https://docs.kubermatic.com/kubermatic/main/tutorials-howtos/kkp-autoscaler/) --- ## KKP Cluster Autoscaler - **URL:** https://www.kubermatic.com/blog/kkp-cluster-autoscaler/ - **Date:** 2026-05-07 - **Description:** Learn about KKP Cluster Autoscaler and how to install it as an addon - **Categories:** Products - **Tags:** KKP - **Authors:** Seyi Ewegbemi ## Kubermatic Kubernetes Platform (KKP) Cluster Autoscaler In a nutshell, it’s a component that automatically adjusts the size of a Kubernetes Cluster so that all pods have a place to run and there are no unneeded nodes. ## What Is a Cluster Autoscaler in Kubernetes? Kubernetes Cluster Autoscaler is a tool that automatically adjusts the size of the worker’s node up or down depending on the consumption. Autoscaler automatically scales up a Cluster by increasing the node size when there are not enough node resources for Cluster workload scheduling and scales down when the node resources are either continuously idle, or there are more than enough available for Cluster workload scheduling. ## **KKP Cluster Autoscaler Usage** Kubernetes Autoscaler in a KKP Cluster automatically scales up/down when one of the following conditions exists: * When some pods fail to run in the cluster due to insufficient resources. * When there are nodes in the cluster that have been underutilized for an extended period (10 minutes by default) and can place their Pods on other existing nodes. ## How to Install Autoscaler on a KKP Cluster You can install Kubernetes Autoscaler on a running KKP Cluster using the KKP addon mechanism, which is built into the KKP Cluster dashboard. You need a running KKP Cluster and a kubectl command-line tool configured to talk to the KKP Cluster. You can easily provision a KKP Cluster by following the steps in our [documentation](https://docs.kubermatic.com/kubermatic/v2.17/tutorials_howtos/project_and_cluster_management/). **Step 1:** Create a KKP Cluster using the documentation link above. **Step 2:** When the Cluster is ready, check the Pods in the kube-system Namespace to determine if Autoscaler is running. ![KKP Dashboard](/static/kkp-dashboard-kkp-autoscaler-blog-post.png) ```bash $ kubectl get pods -n kube-system NAME                    READY   STATUS    RESTARTS   AGE canal-gq9gc                2/2      Running    0       21m canal-tnms8                2/2      Running     0       21m coredns-666448b887-s8wv8   1/1      Running     0       25m coredns-666448b887-vldzz   1/1      Running     0       25m kube-proxy-2whcq           1/1      Running     0       21m kube-proxy-tstvd           1/1      Running     0       21m node-local-dns-4p8jr     1/1      Running     0       21m ``` In this case, Autoscaler is not one of the running Kubernetes components within the Namespace. **Step 3:** Add Autoscaler to the Cluster in the addon section on the dashboard. Click on Addons and then Install Addon. ![KKP Autoscaler addon dashboard](/static/kkp-autoscaler-addon-dashboard-kkp-autoscaler-blog-post.png) Select Cluster-Autoscaler ![Select addon image](/static/select-addon-image-kkp-autoscaler-blog-post.png) Select install ![Install autoscaler addon image](/static/install-autoscaler-addon-image-kkp-autoscaler-blog-post.png) ![Confirmation image that Autoscaler addon is installed](/static/confirmation-image-that-autoscaler-addon-is-installed-kkp-autoscaler-blog-post.png) **Step 4:** Check the Pods in the kube-system Namespace again using the `kubectl` command. ```bash $ kubectl get pods -n kube-system NAME READY STATUS RESTARTS AGE canal-gq9gc 2/2 Running 0 32m canal-tnms8 2/2 Running 0 33m cluster-autoscaler-58c6c755bb-9g6df 1/1 Running 0 39s coredns-666448b887-s8wv8 1/1 Running 0 36m coredns-666448b887-vldzz 1/1 Running 0 36m ``` In the above output, Autoscaler has now been created and is running. **Summary:** Congratulations! You have successfully deployed a Kubernetes Autoscaler on a KKP Cluster for more efficient management of your pods and nodes! The next post will focus on how to annotate the desired MachineDeployments for Autoscaling. Please check out the Learn More section below for more resources on Kubernetes Autoscaler and how to provision a KKP Cluster. ## **Learn More** * Read more on [Kubernetes autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#what-is-cluster-autoscaler) * Learn more on how you can easily provision a Kubernetes Cluster using [KKP](https://docs.kubermatic.com/kubermatic/main/tutorials-howtos/project-and-cluster-management/) * Watch the KKP demo: [Automate Your Clusters Across Multi-Cloud with Kubermatic Kubernetes Platform](https://www.kubermatic.com/resources/automate-your-clusters-across-multi-cloud-with-kkp/) --- ## Command Line Tool for Kubermatic Kubernetes Platform - **URL:** https://www.kubermatic.com/blog/kkpctl-the-command-line-tool-for-kubermatic-kubernetes-platform/ - **Date:** 2026-05-07 - **Description:** Learn more about KKPCTL – a command line tool for Kubermatic Kubernetes Platform. - **Categories:** Products - **Tags:** KKP - **Authors:** Cedric Kienzler, Irina Lindt ## What Is KKPCTL? KKPCTL is a command line tool written by Cedric Kienzler in early 2021 which implements parts of the Kubermatic Kubernetes Platform (KKP) API and lets you access the API via your command line. The way to use it is similar to tools like kubectl. It’s an open source project hosted on <https://github.com/cedi/kkpctl>. ## **The Author** Cedric Kienzler is a software engineer who leads the Kubernetes Site Reliability Engineering team at German Edge Cloud. In his free time he likes to contribute to open source projects, as well as create his own. Cedric created KKPCTL to streamline his work with the Kubermatic API. He also founded Open Infrastructure, a project which focuses on making infrastructure more accessible. ## **Installation** KKPCTL is a go project, so you should have [go installed](https://golang.org/doc/install) and your GOPATH should be set before you proceed with the installation. Instead of installing KKPCTL with go get, follow these instructions to clone and build it: ```text mkdir -p $GOPATH/src/github.com/cedi/ git clone https://github.com/cedi/kkpctl.git $GOPATH/src/github.com/cedi/kkpctl cd $GOPATH/src/github.com/cedi/kkpctl make install_release ``` This installs KKPCTL as a binary tool. To check that it works, run: ```text kkpctl help ``` It should print out the help page: ```text This is a CLI for interacting with the REST API of Kubermatic Kubernetes Platform. Usage: kkpctl [command] Available Commands: [...] ``` If it didn’t work, you should check that the directory with the kkpctl binary ($GOPATH/bin) is in your $PATH. OIDC login: ```text kubectl get configmap -n oauth dex -ojson | jq '.data."config.yaml"' --raw-output | yq eval --tojson | jq '.staticClients | [ .[] | select( .id | contains("kubermatic")) ] | .[].secret' --raw-output ``` ## **KKPCTL Configuration** There are two ways to configure your KKPCTL tool. You can use the `kkpctl` config command, which lets you configure KKPCTL via your command line. This option, however, only supports the openstack provider at the present time. ```text # Add your first cloudprovider kkpctl config add provider openstack --username "user@email.de" --password "my-super-secure-password" --tenant "internal-openstack-tenant" optimist ``` The second option is to manually set your configuration in the config.yaml file, stored in your $HOME/.config/kkpctl directory. You can generate an empty config file with `kkpctl config generate`: ```text # Create an empty configuration kkpctl config generate -w # Edit the just created configuration and fill in the details yourself vim ~/.config/kkpctl/config.yaml ``` ## Working With Clusters With KKPCTL Create your first cluster: ```text kkpctl add cluster --project 6tmbnhdl7h --datacenter ix2 --provider optimist --version 1.18.13 --labels stage=dev kkpctltest ``` List your clusters: ```text kkpctl get cluster --project 6tmbnhdl7h ``` Describe your first cluster: ```text kkpctl describe cluster --project 6tmbnhdl7h qvjdddt72t ``` ## Working With Cloud Providers Here are the options for working with cloud providers: ```text kkpctl add provider $providername # cmdline options: # --cloud $cloudname # uses the specified cloud (Default: uses the cloud defined in ctx.cloud # --type # MUST match the provider name in the configured KKP (i. e. if the KKP supports an openstack cloud provider, this field must be set to "openstack" to enable this config for this openstack provider) # --username # The username for this cloud provider # --password # the password for this cloud provider # --project # the project where to deploy the worker nodes of a cluster # example: # kkpctl add provider optimist_prod --cloud imke-prod --type openstack --username "user@email.com" --password "superSecurePassword!1337" kkpctl get provider $providername kkpctl describe provider $providername kkpctl delete provider $providername ``` ## Working With Context You have the following options for working with context in KKPCTL: ```text kkpctl ctx get # get all context variables kkpctl ctx set cloud $cloudname # set the cloud name to the context, for the cloud to use kkpctl ctx set project $projectname # set the project name to the context, for kkpctl to use ``` ## Connecting Your Kubectl to One of the KKP Clusters This command outputs a kubeconfig file to which you can connect your kubectl: ```text kkpctl get kubeconfig --project 6tmbnhdl7h qvjdddt72t -w export KUBECONFIG=./kubeconfig-admin-qvjdddt72t ``` ## How Can I Contribute to KKPCTL? Since KKPCTL is open source, you can start by looking through [its issues](https://github.com/cedi/kkpctl) on github and finding one that you would like to contribute to. KKPCTL provides an easy way to set up your development environment with devcontainer, which lets you run VSCode inside a Docker container with the setup already prepared for you. See the .devcontainer file in your KKPCTL installation folder. ## How Can I Contribute to KKP? Do you want to contribute to the Kubermatic Kubernetes Platform open source tools? We have a blogpost on that! Find out how you can set up your own development environment [here](https://docs.kubermatic.com/kubermatic/main/how-to-contribute-to-kkp/) and start to contribute to our projects right away! ## Open Source Network of Kubermatic Kubermatic Kubernetes Platform is now open source, which means you can contribute to its projects by submitting pull requests. Here are some projects that you might be interested in contributing to: ### **Kubermatic Kubernetes Platform (KKP)** KKP is an open source project under the AGPL-3.0 license, designed to let you manage Kubernetes clusters across multicloud, on-prem and edge. It is hosted under <https://github.com/kubermatic/kubermatic>. If you want to talk to us about contributing to KKP, you can join the #kubermatic channel on Kubermatic Slack and read [the contributing guide](https://github.com/kubermatic/kubermatic/blob/master/CONTRIBUTING.md) for information on the development workflow and how to complete the Certificate of Origin that we require. ### KubeOne KubeOne is a command line tool designed to let you automate cluster operations on cloud, on-prem, edge, and in IoT environments. It’s an open source project under the Apache-2.0 license and hosted under <https://github.com/kubermatic/kubeone>. For a chat about contributing to Kubeone, join the #kubeone channel on Kubernetes Slack and read [the contributing guide](https://github.com/kubermatic/KubeOne/blob/master/CONTRIBUTING.md) for information on how to participate and complete the Certificate of Origin that is required. ### KubeCarrier KubeCarrier is an open source project under the Apache-2.0 license that enables you to manage applications and services across multiple Kubernetes clusters. It is hosted under <https://github.com/kubermatic/kubecarrier>. If you would like to contribute, you can look through our list of issues <https://github.com/kubermatic/kubecarrier/issues> and see our [guide](https://github.com/kubermatic/kubecarrier/blob/master/CONTRIBUTING.md) on how to contribute to Kubecarrier, as well as the Certificate of Origin required. --- ## Bootstrapping K8s with Ingress: Day 1 & Day 2 Concerns - **URL:** https://www.kubermatic.com/resources/bootstrapping-k8s-with-ingress-dealing-with-day-1-day-2-concerns/ - **Date:** 2024-03-21 - **Description:** Learn more about how to keep the lights on for your running services. # Bootstrapping K8s with Ingress: Dealing with Day 1 & Day 2 Concerns ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Watch the recording and learn more about Day 1 and Day 2 concerns When we talk Day 2, we refer to the monitoring, maintenance and troubleshooting that keep apps, services and hosts up and running. During Day 2 phases, solutions have to adapt to accommodate changing customer requirements based on user and operations feedback. A watchful eye is the key. Automation and monitoring must be at the cornerstone of Day 2 ops if we want to fulfill our SLAs. In this webinar, we take a close look at Day 2 operations and how we can improve the life cycle of a deployment via Kubernetes by using Kubermatic Kubernetes Platform (KKP) and Ambassador Labs Edge Stack for monitoring and scalability. **Speaker:** Daniel Bryant, Director of Dev Rel at Ambassador Labs and Damian Marquez, Senior Solutions Architect at Kubermatic ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## How to Run Virtual Machines With KubeVirt in KKP - **URL:** https://www.kubermatic.com/blog/how-to-run-virtual-machines-with-kubevirt-in-kkp/ - **Date:** 2026-05-07 - **Description:** Learn more about how to run virtual machines with Kubevirt in Kubermatic Kubernetes Platform. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Irina Lindt ## **Introduction** Let’s talk about virtual machines. Can we all agree that Kubernetes and cloud native technologies rock and the cool kids do not want to run VMs anymore? Except that sometimes it actually doesn’t make sense to containerize your workloads. If, for example, your application runs in a VM and requires specific kernel settings. Or if you are running a business-critical legacy application, which would require way too much of an effort to migrate.    So, when you think about modernizing your infrastructure, you might ask yourself questions like: Do I have to rewrite an application (again) so that it will keep doing its job properly? Or do I use my time, money and rather meagre development resources to focus on the next issue and leave the other one in its “still manageable” state? This is where KubeVirt comes in. KubeVirt is an open source technology and CNCF sandbox project that elegantly addresses the needs of development teams that have adopted or want to adopt Kubernetes, but have Virtual Machine-based workloads. In fact, the technology provides a unified development platform where developers can build, modify, and deploy applications residing in both Application Containers, as well as Virtual Machines, in a common, shared environment. (Source: <https://kubevirt.io/>) ## **Why Have We Integrated KubeVirt Into the KKP?** At Kubermatic, we strive to build the world’s most adaptable software delivery platform.  With the Kubermatic Kubernetes Platform you can operate state-of-the-art infrastructure without the need to re-write everything first or manage two systems in parallel. So it was rather obvious to us to integrate KubeVirt, to enable you to run VMs and containers side by side and from a single UI.  Using KubeVirt is simple. You can either use it as an enabler to run side-by-side virtual machines and containers, or it can be rolled out as a complete bare-metal orchestration, based entirely on Kubernetes. ## How to Deploy KubeVirt With Kubermatic Kubernetes Platform To use Kubevirt with Kubermatic, you should first create a cluster via the Kubermatic UI. Use this tutorial to guide you on how to do that. You will then deploy your Kubevirt operator to that cluster.  Here is a screenshot of a cluster created in the UI. ![Cluster created in the UI](/static/how-to-run-virtual-machines-with-kubevirt-in-kkp-cluster-created-in-the-ui-blog.png) When the cluster is fully instantiated, download the kubeconfig as shown in this article and connect your kubectl to that kubeconfig. ```bash export KUBECONFIG=link/to/your/downloaded/kubeconfig ``` The next step is to deploy the Kubevirt operator. First, execute the following in your console to get the newest Kubevirt version. ```bash export VERSION=$(curl -s https://api.github.com/repos/kubevirt/kubevirt/releases | grep tag_name | grep -v -- '-rc' | sort -r | head -1 | awk -F': ' '{print $2}' | sed 's/,//' | xargs) ``` Test it with: ```bash echo $VERSION ``` You should see a version like `v0.44.1`. Now execute the following to install the current Kubevirt operator. ```bash kubectl create -f https://github.com/kubevirt/kubevirt/releases/download/${VERSION}/kubevirt-operator.yaml ``` You should see the following output: ```bash namespace/kubevirt created customresourcedefinition.apiextensions.k8s.io/kubevirts.kubevirt.io created priorityclass.scheduling.k8s.io/kubevirt-cluster-critical created clusterrole.rbac.authorization.k8s.io/kubevirt.io:operator created serviceaccount/kubevirt-operator created role.rbac.authorization.k8s.io/kubevirt-operator created rolebinding.rbac.authorization.k8s.io/kubevirt-operator-rolebinding created clusterrole.rbac.authorization.k8s.io/kubevirt-operator created clusterrolebinding.rbac.authorization.k8s.io/kubevirt-operator created deployment.apps/virt-operator created ``` You should now execute the following to apply Kubevirt custom resource definitions. ```bash kubectl apply -f kubevirt-cr.yaml ``` ## Creating a Virtual Machine With KubeVirt Kubevirt [provides a YAML file](https://kubevirt.io/labs/manifests/vm.yaml) that defines an example of a virtual machine. ```bash apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: testvm spec: running: false template: metadata: labels: kubevirt.io/size: small kubevirt.io/domain: testvm spec: domain: devices: disks: - name: containerdisk disk: bus: virtio - name: cloudinitdisk disk: bus: virtio interfaces: - name: default bridge: {} resources: requests: memory: 64M networks: - name: default pod: {} volumes: - name: containerdisk containerDisk: image: quay.io/kubevirt/cirros-container-disk-demo - name: cloudinitdisk cloudInitNoCloud: # "Hi." in base64 userDataBase64: SGkuXG4= ``` You can apply it as follows: ```bash kubectl apply -f https://kubevirt.io/labs/manifests/vm.yaml ``` ## Conclusion Now that you have seen the Kubermatic way of how to activate and operate KubeVirt, we hope that you’ll remember these key benefits: * You don't have to throw everything away * Don't re-write when you don’t have to * You don't have to operate two systems in parallel ## Learn More About KubeVirt If you would like to learn more about KubeVirt, you can visit the following sites: * [KubeVirt Official Docs](https://kubevirt.io/user-guide/) * [The KubeVirt Page on KKP Docs](https://docs.kubermatic.com/kubermatic/v2.17/architecture/requirements/support_policy/provider_support_matrix/kubevirt/kubevirt/) * [Blog Post: Bringing Your VMs to Kubernetes With KubeVirt](https://www.kubermatic.com/blog/bringing-your-vms-to-kubernetes-with-kubevirt/) --- ## We Proudly Present KKP 2.18 and KubeOne 1.3 - **URL:** https://www.kubermatic.com/blog/we-proudly-present-kkp-2-18-and-kubeone-1-3/ - **Date:** 2026-05-07 - **Description:** Kubermatic releases KKP 2.18 and KubeOne 1.3 with many advanced features for streamlined Day 2 and Day 3 Kubernetes cluster operations. - **Categories:** Company - **Tags:** Announcements - **Authors:** Kristin Wittig Today, we are thrilled to announce Kubermatic Kubernetes Platform (KKP) 2.18 and KubeOne 1.3. Our team has put a lot of thought, love, and sweat into both releases to deliver our biggest update to date. These releases introduce a large number of advanced features to help you securely deploy and operate your Kubernetes clusters in even the most demanding use cases and across any hybrid-cloud, multi-cloud and edge environment. Highlights of the **KKP 2.18 release** include the introduction of edge-ready multi user cluster Monitoring Logging, and Alerting and fortified governance and control features like cluster templates, metering integration, enhanced Open Policy Agent capabilities, and Automatic Backups, all centrally managed from the KKP UI. In addition, the newly added support for AWS Spot Instances allows you to easily optimize for cloud cost, with up to 70% savings. (At least, that's how much we saved on our CI pipeline, by using this feature ourselves) You'll find all of the details in the [KKP release post](https://www.kubermatic.com/blog/kubermatic-kubernetes-platform-2-18-is-here/).  The 1.3 release of our cluster lifecycle management tool **KubeOne** features a new Addons API for an enhanced Addons experience, improved security with managed support for encryption providers, automated Docker to containerd migration, advanced AWS Spot Instances support and much more. For more information, please check out the [KubeOne release post](https://www.kubermatic.com/blog/life-is-hard-kubeone-1-3-makes-it-easier/). Both KubeOne and the Community Edition of Kubermatic Kubernetes Platform are 100% open source and freely available to everyone on Github. We really hope the new releases help you gain power through automation and provide you with the best Kubernetes experience possible. BTW: if you pay close attention while reading our release posts, you might find a hidden Easter egg, so keep an eye out for it! **Attention:** Kubermatic Kubernetes Platform 2.18 will be available for download on September 16, 2021. ## **Learn More** * KKP 2.18 [release post](https://www.kubermatic.com/blog/kubermatic-kubernetes-platform-2-18-is-here/) * Kubermatic Kubernetes Platform [on Github](https://github.com/kubermatic/kubermatic) * KubeOne 1.3 [release post](https://www.kubermatic.com/blog/life-is-hard-kubeone-1-3-makes-it-easier/) * KubeOne on [GitHub](https://github.com/kubermatic/kubeone) --- ## Kubermatic Kubernetes Platform 2.18 Is Here! - **URL:** https://www.kubermatic.com/blog/kubermatic-kubernetes-platform-2-18-is-here/ - **Date:** 2026-05-07 - **Description:** The latest release of Kubermatic Kubernetes Platform comes with advanced features to ensure smooth Day 2 and Day 3 operations of your Kubernetes clusters. - **Categories:** Products - **Tags:** KKP - **Authors:** Sascha Haase, Chiara Schieder Today, we are excited to announce the latest release of Kubermatic Kubernetes Platform (KKP). Through our dedicated efforts we are pleased to offer our community one of the most significant updates to date, which includes some great new features like multi user cluster monitoring, logging, and altering, cluster templates, new metering integration, and Open Policy Agent enhancements. Our commitment towards providing the most adaptable and autonomous software delivery platform in the market led to advanced features for both the Enterprise Edition (EE) and the Community Edition (CE). By making Day 2 and Day 3 operations more streamlined than ever before, Kubermatic gains technological leadership for Kubernetes automation and platform operations. Here are some of the highlights of this release. ## **Edge-Ready Multi User Cluster Monitoring, Logging and Alerting** (CE and EE) Here comes the future! Setting up and configuring edge-ready Monitoring, Logging and Alerting of your Kubernetes installation requires a lot of knowledge and can quickly become an operational nightmare. That’s why we’ve taken this on for you. KKP 2.18 offers a full integration with the best-in-class open source tools, Prometheus, Grafana, Loki, and Cortex, to minimize your investment, both in time and money. Enabled on demand or enforced on any user cluster with just one click from the KKP UI.  ![KKP Defaults for User Cluster Settings ](/static/kkp_mla-architecture.png) This empowers every organization to adapt this essential functionality specifically to their needs. Of course, the permissions are linked to the roles associated with the platform and everything can be accessed via the dashboard.  But the best part about this new feature is: By accumulating all of the data in our seed cluster, you only need the absolute minimum on your user cluster, which makes it a perfect fit for a highly distributed edge-scenario where every piece of memory counts. (For those of you who are number savvy, the default requests Prometheus 256Mi memory, 100m cpu to be precise.) Take a look at the [architecture](https://docs.kubermatic.com/kubermatic/main/architecture/monitoring-logging-alerting/user-cluster/) to familiarize yourself with the concepts and get the most out of your setup. ![Monitoring, Altering, and Logging architecture with KKP](/static/monitoring-altering-and-logging-architecture-with-kkp2.18_release_kkp_blog_post.png) ## **Deploy Optimal Clusters Instantly with Cluster Templates** (CE and EE) ![KKP cluster templates ](/static/kkp_cluster-templates.png) Make your life easier by deploying clusters faster with our new Cluster Templates. Create a cluster with all of the settings that you need, then save it as a template. Now you can create the same cluster as many times as you want with just a few clicks. Even better: give your team members or the whole organization access to the template to streamline your processes. Templates are available at a user and project level or on a global level for admins. ## **Keep Control of Your Resources With Metering Integration** (EE only) ![Metering with KKP](/static/kkp_metering.png) Fetch all usage data for user clusters and save it in one place. Download the CSV file and evaluate the data for your needs, whether optimization, attribution or billing. Use our UI for easy configuration and management. ## Never Lose Your Cattle Again - Backup & Restore UI (CE and EE) You’ll love having our new Automatic Backups enabled – Get backups as often as you need and retain them for as long as you want. Alternatively, take snapshots of your current cluster state and save it for later. Restore from a former state or create new instances, based on your backups and snapshots. Easily configure the backup intervals, expiry and buckets with our brand new UI. ![KKP backup and restore UI](/static/kkp_backup-ui.png) ## **Optimize Your Workload With Advanced AWS Spot Instances Support** (CE and EE) For power users that really scale out, cloud works really well. On the other hand, the potential to optimize costs is quite substantial. We integrated advanced AWS Spot Instances support to configure not only Spot Instances but what you’re willing to pay for them as well. In combination with our unique machine controller, rescheduling of nodes is done without interruptions. For more sensitive workloads, KKP can run machine deployments with Spot Instances and reserved Instances side by side in a single cluster. Eating our own dog food, we were able to save 70 percent in the machine costs of our CI Pipeline by consuming advanced Spot Instances. ## **Enhancements on Open Policy Agent for Default Constraints and Allowed Container Registries** (CE and EE) The integration of the Open Policy Agent that we introduced with the 2.17 release was just the first step towards more secure and compliant workloads. With 2.18, you can now apply OPA Default Constraints right out of the box. Do it once, roll it out everywhere. ![Default Constraints in the Admin Panel](/static/default-constraints-in-the-admin-panel_release_kkp2.18_blog_post.jpg) To lift even more weight off your shoulders, we’ve added the option to define all of the container registries that are allowed to deliver images into KKP. This provides even tighter security and gives you better control over your container platform. ![Allowed Registry in the Admin Panel](/static/allowed-registry-in-the-admin-panel_releae_kkp2.18_blog_post.jpg) ## **KubeVirt Cloud Controller Manager Integration** (CE and EE) When providing a container platform, sooner or later bare metal machine support becomes a topic. With this release, you can lie back and relax, and count on KubeVirt for this. Kubermatic Kubernetes Platform natively works with KubeVirt like any other cloud provider, which allows you to take full advantage of the amazing progress that project has achieved. Split your bare metal machines into smaller segments and make the most of your data center. ## **CCM and CSI Migration on Distinct Cloud Providers** (CE and EE) We’re now automatically deploying a CSI driver for all supported providers, so you can use cloud provider-backed volumes. In addition, the external cloud controller managers (CCMs) have been updated to their latest versions for all supported providers to include the latest bug fixes and improvements. We’ve also implemented a CCM/CSI migration for OpenStack and vSphere clusters to answer the in-tree cloud providers’ deprecation. Originally, the controllers responsible for connecting your clusters to the cloud provider, (i.e., in-tree cloud providers) were integrated directly into Kubernetes. Those controllers are now considered deprecated, replaced by external cloud controller managers (CCMs) and CSI drivers. KKP 2.18 now allows for simple and smooth migration of your existing OpenStack or vSphere clusters using in-tree cloud providers. ## **Easily Migrate From Docker to Containerd Container Runtime** (CE and EE) The Kubernetes 1.20 release deprecated support for Docker (dockershim) as an underlying container runtime. With the upcoming Kubernetes 1.23 release, the support for Docker as a container runtime will be entirely removed. Instead, a container runtime compatible with Container Runtime Interface (CRI), such as containerd, must be used. This means that you can still use Docker in your development workflow, but a CRI-compatible container runtime must be used on Kubernetes nodes. That’s why we’ve already introduced containerd support in our previous 2.17 release. Now you can easily migrate your remaining Docker clusters to containerd with just one click. ## **Always Run the Latest Kubernetes Version**  (CE and EE) We are always doing our best to provide support for the most current Kubernetes releases. Kubernetes 1.22 is supported with this release, so you can enjoy all of the new features and improvements. **Attention:** Kubermatic Kubernetes Platform 2.18 will be available for download on September 16, 2021. And... we’re really looking forward to announcing another innovation at ContainerDays which runs September 21 - 23, 2021. Please [join us!](https://www.containerdays.io/) Wow….that’s a lot of “new”...what a release! If you made it this far, you definitely deserve a reward. The first five people to write to us at [marketing@kubermatic.com](mailto:marketing@kubermatic.com) will get one of our brand new, amazing Automation Superhero T-shirts!  We are very interested in your feedback on the new release, as well as your KKP experience overall. You can reach out via [Github](https://github.com/kubermatic/), {{< slackjoinlink "Slack" >}}, or [many other ways](https://www.kubermatic.com/company/community/#discussions). ## **Learn more** * Check out the entire [Changelog](https://github.com/kubermatic/kubermatic/blob/master/CHANGELOG.md) * Check out our [documentation](https://docs.kubermatic.com/) --- ## Life Is Hard, KubeOne 1.3 Makes It Easier! - **URL:** https://www.kubermatic.com/blog/life-is-hard-kubeone-1-3-makes-it-easier/ - **Date:** 2026-05-07 - **Description:** KubeOne 1.3 brings many exciting features including automated Docker to containerd migration and a brand new Addons API. - **Categories:** Products - **Tags:** KubeOne - **Authors:** Sascha Haase, Marko Mudrinić Today, we are pleased to announce that KubeOne 1.3 is now generally available. KubeOne is our open source cluster lifecycle management tool that automates cluster deployment and management in your preferred cloud, on-prem, edge, or IoT environment. The previous release paved the way for a lot of new features and this time we are excited to present those features to you. KubeOne 1.3 brings a brand new Addons API, managed support for encryption providers, automated Docker to containerd migration, and much more!  Here are the major highlights of this release: ## **Enhanced Addons Experience** We introduced KubeOne Addons back in the KubeOne 0.11 release, which offered an easy to use mechanism for deploying various additional components to improve the user experience. It did, however, require you to provide the YAML manifests along with the KubeOneCluster manifest, even if you used the addons we provided. We heard your feedback and we’re introducing several improvements with this release, including the new Addons API. Now, all of the addons that we provide (e.g., cluster-autoscaler) are embedded in the KubeOne binary. If you want to use any of these addons, you can just request them in the KubeOneCluster manifest using the Addons API. In addition, all existing Go structs used for deploying the core components, like the machine-controller, have been replaced with YAML-based Addons. If you want to change any component we deploy, all you have to do is put the appropriate manifest in your addons directory. There’s no need to change anything in code or recompile KubeOne. Find out more about the new API along with how to use all the latest features in our [Addons guide](https://docs.kubermatic.com/kubeone/v1.3/guides/addons/). ## **Improved Security With Managed Support for Encryption Providers** Kubernetes Encryption Providers allow you to encrypt your data at rest. This means that selected resources will be stored in an encrypted form in etcd. KubeOne 1.3 provides managed support for Encryption Providers for the following operations: * Enabling/disabling Encryption Providers * Generating and rotating encryption keys * Using custom Encryption Providers configurations * Using KMS-based Encryption Providers Enabling Encryption Providers based on AESCBC for all Secret objects in the cluster is as easy as using the following KubeOneCluster manifest and running `kubeone apply`: ```yaml apiVersion: kubeone.io/v1beta1 kind: KubeOneCluster versions: kubernetes: '1.22.1' features: encryptionProviders: enable: true ``` Check out our [Encryption Providers docs](https://docs.kubermatic.com/kubeone/v1.3/guides/encryption_providers/) for more advanced use cases, such as how to use a custom configuration file, as well as information on KMS-based providers. ## Automatically Migrate Your Clusters to Containerd The Kubernetes 1.20 release deprecated support for Docker (dockershim) as an underlying container runtime. With the upcoming Kubernetes 1.23 release, the support for Docker as a container runtime will be entirely removed. Instead, a container runtime compatible with Container Runtime Interface (CRI), such as containerd, is required. This means that you can still use Docker in your development workflow, but a CRI-compatible container runtime must be used on Kubernetes nodes. That’s why we’ve introduced containerd support in our latest 1.2 release. Now you can migrate your remaining clusters running Docker to containerd by running a single command. ![Docker to containerd migration](/static/docker-to-containerd-migration_kubeone_blogpost.png) In addition, containerd is now supported on Flatcar Linux with this release, so you can provision Flatcar Linux clusters running containerd, or migrate your existing clusters.  If you want to learn more about this feature, we recommend checking out our [migration guide](https://docs.kubermatic.com/kubeone/v1.3/guides/containerd_migration/). ## **Optimize Your Workloads With Advanced AWS Spot Instances Support** For power users that really scale out, cloud works really well. Costs on the other hand have a large potential for optimisation. We integrated advanced AWS Spot Instances support to configure not only Spot Instances but what you’re willing to pay for them as well. In combination with our unique machine-controller, rescheduling of nodes is completed without interruptions. For more sensitive workloads, KubeOne can run machine deployments with Spot Instances and reserved Instances side by side in a single cluster. Always keen on eating our own dog food, we were able to reduce the machine cost of our CI Pipeline by 70 percent by consuming advanced Spot Instances. ## **Improved Support for OpenStack, vSphere, and Hetzner** The new release brings many improvements to OpenStack, vSphere, and Hetzner. We’re now automatically deploying a CSI driver for all three providers, so you can use cloud provider- backed volumes. In addition, the external cloud controller managers (CCMs) have been updated to their latest versions for all supported providers to include the most current bug fixes and improvements. We’ve also implemented a CCM/CSI migration for OpenStack and vSphere clusters to answer the in-tree cloud providers’ deprecation. Originally, the controllers responsible for connecting your clusters to the cloud provider, (i.e., in-tree cloud providers) were integrated directly into Kubernetes. Those controllers are now considered deprecated and replaced by external cloud controller managers (CCMs) and CSI drivers. If you still have OpenStack or vSphere clusters using in-tree cloud providers, you can now easily migrate them using just a single KubeOne command. ## **Cover Highly Complex Use Cases With our Empowered KubeOneCluster API** In addition to the Addons API, the KubeOneCluster API has improvements to better support advanced and enterprise use cases. You can now provide a custom CA bundle that can be used by the control plane components, including CCM, CSI, and machine-controller. This is a very important feature for OpenStack and vSphere clusters if your setup uses a custom CA, which is not trusted by operating systems out of the box. There are also new options for configuring kube-proxy. You can choose between running it in the iptables mode, which is the default, or in the IPVS mode. Running kube-proxy in the IPVS mode offers some additional options, such as enabling strict ARP, choosing a scheduler, or configuring timeouts. You’ll find some of those options useful, especially if you’re a MetalLB user or want to utilize better scalability of IPVS. ## **Kubernetes Support Policy Changes** The latest Kubernetes 1.22 is supported with this release, so you can enjoy all of the newest features and improvements. **Attention:** Kubernetes has deprecated many old APIs in Kubernetes 1.22, so we had to change the minimum supported Kubernetes version to 1.19. If you have any clusters running Kubernetes 1.18 or older, make sure to upgrade to 1.19 using an older KubeOne release before upgrading to KubeOne 1.3. The [Compatibility document](https://docs.kubermatic.com/kubeone/main/architecture/compatibility/) includes a list of supported Kubernetes versions for each KubeOne release. The new release introduces many other features, we recommend checking out the entire changelog. If you’re an existing user upgrading to KubeOne 1.3, please pay additional attention to the “Attention Needed” part before upgrading. We hope the new release of KubeOne helps you operate your Kubernetes clusters more easily and painlessly, regardless of the underlying infrastructure. If you want to support our project, leave us a star on Github and share your [ideas and thoughts](https://www.kubermatic.com/company/community/#discussions) with us. We are always very interested in how you use KubeOne and how we can improve. ## **Learn More** * Read the entire [changelog](https://github.com/kubermatic/kubeone/blob/master/CHANGELOG.md#v130---2021-09-15) * Check out the brand new KubeOne 1.3 release on [Github](https://github.com/kubermatic/kubeone/releases/tag/v1.3.0) --- ## Manage K8s Applications Effortlessly With KubeCarrier - **URL:** https://www.kubermatic.com/resources/how-to-manage-thousands-of-kubernetes-applications-using-kubecarrier/ - **Date:** 2024-03-21 - **Description:** Learn how to easily manage services across multiple clusters using our open source KubeCarrier service hub. # How to Manage Thousands of Kubernetes Applications With Minimal Efforts Using KubeCarrier ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Watch the replay of our CNCF on-demand webinar One of Kubernetes greatest – and most difficult to keep – promises is the ability to eliminate much of the operational burden of managing applications and services on multi-cloud infrastructure. Kubernetes Operators deliver on this promise by automating the management of applications and services lifecycle. However, provisioning, reconfiguring, and tearing down applications and services across multiple clusters is still hard and time-intensive.  KubeCarrier is an open-source project for managing services across multiple Kubernetes clusters and provides facilities to provide services to internal and external users in a self-service catalog. In this talk, we demonstrate how to use KubeCarrier to automatically manage the full lifecycle of applications and services to end-users with the self-service catalog and to easily manage services across multiple clusters, independent of cloud, data center, and region. **Speaker:** Jiacheng Xu, Software Engineer at Kubermatic ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Are You Looking for a Cost-Efficient Alternative to VMware? - **URL:** https://www.kubermatic.com/resources/are-you-looking-for-a-cost-efficient-alternative-to-vmware/ - **Date:** 2022-12-01 - **Description:** Check out why KKP may be the excellent alternative for you in comparison with VMware # Are You Looking for a Cost-Efficient Alternative to VMware? ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Business Case ## Get our comprehensive KKP vs VMware comparison and see why KKP may be the excellent alternative for you In today’s fast-paced world, you need to rapidly deliver innovative applications powered by containerized infrastructure. We admit….VMware is doing a not so bad job with this. However, it is also three times more expensive than alternative solutions - like ours! Before you invest the time and money, you might want to consider other solutions out there that are both cost-**effective** (getting results, no matter what they cost) **AND** cost-**efficient** **(getting the result without overspending)**. If so, then Kubermatic Kubernetes Platform (KKP) may be an excellent alternative. KKP is a Kubernetes management platform designed specifically for the needs of enterprise customers. It addresses the operational challenges of managing Kubernetes at scale while enabling teams with a self-service developer and an operations portal. With KKP, you can take advantage of a truly independent and infrastructure-agnostic platform, competitive pricing with a consumption-based subscription, strong community advocacy and rapid implementation of feature requests. ### **There are many strong reasons why to choose KKP over VMware…** ![KKP vs VMware Comparison](/static/kkp-vs-vmware-comparison.png) ### **…download the full comparison and convince yourself!** [Download](https://f.hubspotusercontent40.net/hubfs/4550048/Marketing/VMare%20vs%20KKP.pdf) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Audit Logging in Clusters - **URL:** https://www.kubermatic.com/blog/audit-logging-in-clusters/ - **Date:** 2026-05-07 - **Description:** Learn more about how to configure audit logging in Kubernetes. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Irina Lindt ## Introduction Whenever you change something in your cluster, you might want to log that change somewhere so that you can look it up later. Did you know that Kubernetes not only lets you log all changes but also fire events that respond to particular changes? Find out in this article how to do this! Audit logging is a feature that was introduced in Kubernetes v1.11 and added new features in v1.13. Every event is logged as a JSON file that holds information about the event that might be useful for you when troubleshooting. This article provides an in depth view of and how to configure audit logging. ## Why Do You Need Audit Logging? One obvious use case for audit logging is cluster debugging. The logs record changes in the cluster state, and you can review them to see if misconfiguration is a source of the errors. Another use case is troubleshooting. Since the logs record which request came from which component and provide a timestamp, you can use them as a time-series of events in your cluster that can tell you what went wrong. You can also use audit logging for performance tuning. Since the logs document what happened and how often requests were made, looking at them is sometimes the only way to find out from the documentation if some types of requests get fired more often than you would expect and are causing a heavy load on the cluster. ## What Can Audit Logs Tell You? Audit logs record the following information about every request: * What happened? * When did it happen? * Who initiated it? * On which component did it happen? * Where was it observed? * From where was it initiated? * To which component was it going? * Where audit log events are generated All audit log events are generated in the Kubernetes API server. Kube-apiserver is the central component of a cluster and controls the cluster state. All requests that modify the state of the cluster pass through the API server. This makes kube-apiserver the ideal choice for implementing audit logging. ## Example of an Audit Log Event Each event is recorded as a JSON document. To see an example of an audit log event, you can install the JSON parser `jq` from [here](https://stedolan.github.io/jq/) and search the audit logs with ```bash tail -l /var/log/audit/audit.log | jq . ``` This command finds one logged event, forwards it to the JSON parser jq for pretty formatting and prints out the event. Here is an example: ```json { "kind":"Event", "apiVersion":"audit.k8s.io/v1beta1", "metadata":{ "creationTimestamp":"2018-03-21T21:47:07Z" }, "level":"Metadata", "timestamp":"2018-03-21T21:47:07Z", "auditID":"20ac14d3-1214-42b8-af3c-31454f6d7dfb", "stage":"RequestReceived", "requestURI":"/api/v1/namespaces/default/persistentvolumeclaims", "verb":"list", "user": { "username":"irina@loodse.com", "groups":[ "system:authenticated" ] }, "sourceIPs":[ "172.20.66.233" ], "objectRef": { "resource":"persistentvolumeclaims", "namespace":"default", "apiVersion":"v1" }, "requestReceivedTimestamp":"2018-03-21T21:47:07.603214Z", "stageTimestamp":"2018-03-21T21:47:07.603214Z" } ``` ## Searching Audit Logs Using Falco Most users rely on jq to search audit logs, but Sysdig developer Mark Stemm states that the Falco tool is “the easy way” to search audit logs and is more user-friendly. If you are interested in Falco, you can view his intro talk [here](https://techconf.me/talks/45781). ## Components of Audit Logging There are two components that handle the configuration of audit logging. First is the Audit Policy which controls which events get logged. The second component is Audit Backend which handles the persisting of audit events to an external storage. Let’s look at both components in more detail. ## Audit Policy The audit policy defines the configuration of audit logging. It controls which events go into the audit stream. The audit policy is defined in a YAML file, in which you can stipulate for every type of event as to whether it gets logged and at what level. Here is an example of an audit policy YAML file: ```yaml apiVersion: audit.k8s.io/v1 # This is required. kind: Policy # Don't generate audit events for all requests in RequestReceived stage. omitStages: - "RequestReceived" rules: # Log pod changes at RequestResponse level - level: RequestResponse resources: - group: "" # Resource "pods" doesn't match requests to any subresource of pods, # which is consistent with the RBAC policy. resources: ["pods"] # Log "pods/log", "pods/status" at Metadata level - level: Metadata resources: - group: "" resources: ["pods/log", "pods/status"] # Don't log requests to a configmap called "controller-leader" - level: None resources: - group: "" resources: ["configmaps"] resourceNames: ["controller-leader"] ``` The format is straightforward. First you can use the parameter “omitStages” to define the stages at which requests don’t get logged. In this case these are events in the “RequestReceived” stage. What you need to know here is that requests don’t just get recorded once, they can actually get logged at various stages in the lifecycle of a request. ## Stages of a Request The four stages at which a request can be logged are defined as follows: * `RequestReceived`: You can log requests before the server has started issuing a response. In our case the administrator has decided that this stage is too inconsequential to be part of the logs. * `ResponseStarted`: The headers of the request have been completed but no response body has been sent off. * `ResponseComplete`: Requests get logged at this stage when their response body has been completed. * `Panic`: This is the stage that gets logged if a panic has occurred. The parameter ”rules” is the only required parameter in the Audit Policy YAML file. This is where you can define which requests get logged at which level. For example, the first rule states that all changes in pods are logged at the RequestResponse level. ## Levels of an Event The first rule dictates the audit level of the event. The defined levels are: * None: Events that match this rule shouldn’t get logged. * Metadata: Only logs the metadata of the request but not its request or response body. * Request: Logs the metadata and the request body of the event but not the response body. * RequestResponse: Logs event metadata, request and response body. This is the most informative level but can generate a high load on your cluster. ## Audit Backends Audit backends allow you to write your audit logs to an external storage. Kubernetes provides two options for this: * the log backend writes logs to a filesystem * the webhook backend sends events to an external HTTP API ## Log Backend The log backend uses the JSONlines format to write logs to a file. To configure the log backend you have to provide the file to the kube-apiserver using the flag `--audit-log-path`. ## Webhook Backend The webhook backend sends your audit events to an external API. You can configure it by providing a configuration file with the kube-apiserver flag `--audit-webhook-config-file`. ## Conclusion Audit logging is a secure, sequential record of all actions in a cluster, which audits user-generated activities, applications that use kube-apiserver, as well as those generated by the control plane. Audit logging provides useful features for troubleshooting and performance tuning in Kubernetes clusters. ## Where to Learn More * [Webinar: K8s Audit Logging Deep Dive](https://www.youtube.com/watch?v=WJ3w-hyt0hY) * [Blog Post: Setting up OIDC Authentication & Audit Logging With Kubermatic KubeOne](https://www.kubermatic.com/blog/kubeone-oidc-authentication-audit-logging/) --- ## Kubermatic News for August 2021 - **URL:** https://www.kubermatic.com/blog/kubermatic-news-for-august-2021/ - **Date:** 2026-05-07 - **Description:** Check out August's Kubermatic news, learn more about online course - **Categories:** Company - **Tags:** Announcements - **Authors:** Sebastian Scheele ## ContainerDays Are Back in Hybrid Form Good news for all cloud enthusiasts and container fans around the world: **ContainerDays (CDS) will once again take place September 21-23, 2021**. After a forced break in 2020, **Europe’s flagship conference** on container and cloud native technologies is going hybrid this year: The ContainerDays team and Kubermatic as a sponsor are both looking forward to welcoming 250 participants live in Hamburg while the entire community worldwide can join the online conference for free. Since its first edition in 2016, ContainerDays has always been the place to discuss and define the future of cloud native. Taking a sneak peek at the CDS agenda, the current “hot topics” in the community are: T**he Edge, GitOps, Machine Learning and AI. Over 50 international speakers** will share their expertise on these and many other topics. For us, this year’s ContainerDays 2021 will be a very special edition – being able to **gather the community in Hamburg again**, and celebrating the **5th anniversary of Europe’s flagship conference**. We are very pleased to be able to host this event again, even though as a downsized version compared to previous years for those attending in person, as well as a massive response for online participation. The onsite attendance of many sponsors and speakers continues to confirm the importance of in-person exchanges and offline networking. We are very much looking forward to an amazing conference and meeting all of our old and many new friends from the community. If you're curious about the cool things we're planning for CDS – read on. And make sure that you save your seat. #### **[Get Your Ticket](https://cxwn804.na1.hubspotlinks.com/Btc/LW+113/cxWn804/VWcp5-3KrWw_W90DYR18ZXG_bW8LzBkh4wq7smN880g3m3lSbtV1-WJV7CgGrxW7GrTZp97RmbfV-78Bt3kSRMTW1xFbP24y89vFW5TfVth8JlCJvW3Qc8yj1CCLWLW61jZP-558DgvN4r-r25mT_WzW83WpK676ns1hW80d2Cx2rMQXRW9ftXKb6ppdbFN2Rh-qtgfMTRW7d88182bhYD5W25QdGP1hlChPW34bBBt2QPDV9W71V-rN1JbdyhW4_R8d9673PVtN35w45CD6_YKW73xYR1129Nz5W59G5lT3SmFc7W70vsyM2Rqcwb3cg-1)** Excited to have you join us! ⠀ ## **So What’s Happening at CDS?** ![Ship, Kubermatic talks](/static/kubermatic-talks_ship_blog-post.png) [Goodbye Pod Security Policy - Hello Stronger Alternatives](https://it.t.hubspotemail.net/e2t/tc/VWsRHw2vR2rQW8MKs4F2PN1mTW7RdXLG4wnfgmN2QYvzD3lHNGV1-WJV7CgC4sW93rPLG5rWwszN1TFlfTX1_WFW28J8828mV2TTN7MT6GlYQZLvW2vFPZh24CSl3Vzxc472Nt2jZW8Mq-Qh28Rz2_W7c0rkF6b_x9wW36_FsZ6-2mn4W1gJsXB2Yb2KSW9ckrd57QTg7yW616dRN7ZTPkBW1x-m312VH32kW6zgbJ_3nxcJKW6V1Q3l42hnzkW6DV4Sd8FFg65W58ZKCk15bB3JW7MVn7L4xV_xnW3YQ8wY388Ny3W7L4Sn83jh88RW63WK0k2-xZZjN7HXmZJsPSWT311N1) [📢](https://lh4.googleusercontent.com/5d2-oWLRZQRWnIBQlDMs952EXXyjFs8SdZmgkyqJfmnqhKbFpTaarpoAoWzxUOPRQPCDeMG6pogLVIm3ZZcudjuyfEMrl8EwDjML6zk6GrNRuugLuk2e-d_M4rhozkJXdDrslzrW) Mario Fahlandt, Kubernetes Consultant at Kubermatic [📆](https://lh6.googleusercontent.com/hNDutkGnsGTGDeKhVoDT_jGe-1_EvGhCltuAJIf9g0rFNiSa0RjMMVlX9BD1h1HJ36Ojt_AJbsxw7HlvE98I6-Pvwl8-nJwIovNrLSIfBXMP3z8nl2EvRqeHPCqyoqYCKIM22hYL) Tuesday, September 21 at 12:10 PM CEST **[💡](https://lh4.googleusercontent.com/oJG7btoJc4WGOT0xpC4eZ-5YcCDsMq73UoaYyHg33aXG3GR13rJ4gox-iAVZjsNbHEhJI9L9_sYc4BR3-o7R-9k2BZlV_64RcyNa3Rlyx3260BRHhJ-vgkYNVWMsh7VJPd8QY96A)** #Intermediate #Security #Onsite Talk ⠀ [The 7 Deadly Sins in Kubernetes](https://it.t.hubspotemail.net/e2t/tc/VWsRHw2vR2rQW8MKs4F2PN1mTW7RdXLG4wnfgmN2QYvzD3lHNGV1-WJV7CgPddW95Mn7t3pLShfVnc5_K5Nhpg0N71zL1CcZPBTW1V8VsQ4K6TNNW3GXxf_89qZFBW7Z_B1J8C1-FVW3-K5lX8YHw-dW1cXMlH5WhtXNN6njcCNxZZPfW56W-cV6l0rmZV2LH8p1qS08RW4ZZxFl2--htTW91MDd_3DGFkhV93-WZ4RJgcxW4FyqlG6C4MY-W8ycFM16pphM5W2Y_kgb5KL2x1W6ljwrj6DlMnNN4h9KK7590QSW3Crhnp2gdD-YW5zF4kz2T_zZ2W854XgN5s69wR3fqZ1) [📢](https://lh3.googleusercontent.com/5hFGBr9SNBEFT2VTgS26nGqxP33rjqgV9IMqWOlAYz4heb_eJOZCvu_xO8vPwt9neIVnm_W8hHF2xUsLJqYUOmxWoNIuEu0wd7Szm97F92UbpWWMdM6LA2IyX7-pMyJqNg2_07wp) Hubert Ströbitzer, Kubernetes Consultant at Kubermatic [📆](https://lh5.googleusercontent.com/kQHXHqQ09P8TTA70wBT7MbH4BVb90Tr5yp1nPw61FTYJpBZ6jsUo9Uo7X9X49Rumk76HvFwowWpKugxXn-fR_vaH6W31D9yq1GmpaFKofmvMpaBPUwNPHexHCiF92yLTGQffFNbr) Wednesday, September 22 at 10:50 AM CEST [💡](https://lh6.googleusercontent.com/Dj9UAG59jfrWvtZOyzguhAIIAkdRGmLc5PrlDGF7X-DrtT3z9BuFzYJpk5aida3G-DYFDgkfIdDji6dXT2aJL_VxDxtbmtlnPAeCMLt4AG2FFIG6p4JogTu8AT5iGvWgWjS6zb2N) #Beginner #Developer #Onsite Talk ⠀ [Dockerfile Best Practices - How to Create Secure and Efficient Images](https://it.t.hubspotemail.net/e2t/tc/VWsRHw2vR2rQW8MKs4F2PN1mTW7RdXLG4wnfgmN2QYvzD3lHNGV1-WJV7CgCn9W6vRTMc941-NhVKgh_S3NZTB4W9btVXc8dCBfwW1Dt9Xc5NQzzrW2Jq7MD9gTz2fW9bWszz1q8h80W8Wb_rN1tpprCW8W5lYy8DkS2VW5BCbHv8CMMb6W830ZT01NghpkW2zbLHg6Tl_5cW4t0_Bg20mHPRW48C-D169-WH2W8RzbwG2DCG26W6j5KDB8l8QhJW957L_74LqXP9W315C5f7Hc024VSrLq38QQgyMVzW9hj7gCQhnW7LJ4l68pvqxvW73W51q12cZ1xN75XC5JKF8VD3dJV1) [📢](https://lh3.googleusercontent.com/gesv0KYixGwdEF05Y9W3XyAEUblqcBXmkjmmbL6DuPDU4BjKUccKO5gD2RLrY2A0mFxi40HBSMTmrKZDiJRSlAVHGPqVfQm7WNxb8MBVa2CPEl6elJZ8nXGwBO2wwUzC4eVeePYb) Koray Oksay, Site Reliability Engineer at Kubermatic [📆](https://lh3.googleusercontent.com/y6LPy5Aq295uHe1V0FY2wH2Esw4eXe7F2VIFbDQM83EYCpfmk3Hlj-M-muyZnTlc2PFsQXuaQce8-gQP_8_B7qkcHgcEol0p51iKIWoDiPtWKdspwJIrvagZCVJio4fMcxLCP6Go) Wednesday, September 22 at 11:30 AM CEST [💡](https://lh5.googleusercontent.com/BbyxuzNqjr7qoBumIYUJ3_AlNTPzK4MzVsUXM1cw6rJ4bpjOgmbst7i04mN3zLE_QHSsL-CcmXYYi8yN11sfm6I7ylmH9UmFS3P_7NLEiPkz_k3mhCxOcF8qhdIx__1GcDez5dMa) #Intermediate #Technical #Onsite Talk ⠀ [Kubermatic's Inception With GitOps - Why Not?](https://it.t.hubspotemail.net/e2t/tc/VWsRHw2vR2rQW8MKs4F2PN1mTW7RdXLG4wnfgmN2QYvzD3lHNGV1-WJV7CgM9yVMmMFx4xzhVVN7bh3YVLvVqlN4XQhQrP_5l3VMsfPq8_pwpsW7TLr4C7xcJkqW7v7Ddq8-9JbDW7LvPZw3fk_7nW7Ryr9h6TDfTpW4Cbn5H8r1ZbGN8lDvwh2vW8WW6DkXkl29-D4fW1hCkxT7dDc0zN47JbKnqtZpBW7m47vG6sK6LZW7kjDpS6m6zlrW2mQllq3BnxHmW4Qk1HL7_fBQ9W22583w77Ck28W2FP0k52NxKp2VRW8SK4M8ZQxW34rmkw5pvt26W6XHR7w1cTtMP356m1) [📢](https://lh6.googleusercontent.com/bFt4eMgs2TlAVm2noM6EEdivn19h2pGPhxu-LNKycZhMIxle1GQWcoW3ED-ncHWhiGNTgDnvhCNsfyBzaPnGevLGFZbWl_-sY96rSwbRrkL8bMtfve3Ks-Sc6ohG7MXM_NgF9wZf) MichalVančo, Kubernetes Cloud Architect at Kubermatic [📆](https://lh6.googleusercontent.com/PgPj7onxPCKuoNwV1e4aofCfBCQq4xwYVPOygkNNIA0ZYoS6o2H3VuSA3U53OkWbhivfCR1YHNrEulu9VvDW-gXcqCF1XjvtEbl27M0UDeKYcRZKGX8a5J9rVycMyygxefmtxvZ3) Wednesday, September 22 at 14:10 PM CEST [💡](https://lh6.googleusercontent.com/7JuuKIW50M_4nTlpp1vDDYmsMvzh8Jh5Fm5YWFLv9juuo4zXbwkex3Wlwju5zaGs6BDh9MXnsLX2Kd1OA1NDNokvOI0IWeqMFxPqRBuADUyofdYOGnDeO6f75WOn7XAvuYseAA-F) #Intermediate #Technical #Onsite Talk #### **[Check Out the Agenda](https://cxwn804.na1.hubspotlinks.com/Btc/LW+113/cxWn804/VWcp5-3KrWw_W90DYR18ZXG_bW8LzBkh4wq7smN880g3G3lSbNV1-WJV7CgF61W8SmvbZ8xhxwhVjyHYR3Jt2-_W1d6YBS27kK5pN3f7BHXXRQsGN5dLCNHvqvBCN8jwV_pVkt0cW8Sh25k6fdWNgM8pvFg_XTsWN50rmKsbgJf-W85g5hM6fH87-W6xxnF56fHQYRW3y-qSC5d26N8W6D2S7z30pjTTW2gl8ZW7NCgQgN73mH2Qmj0ZfN3gH6k-R1xmpW34QzgQ3J7T6JW5ZMF7j6WL_T4W7WPXjp6kJwq7W6mwfcn3n08FcW2j-T5G88DnlrW4ZXvfM60vnRb3j8d1)** ⠀ ![Anker - Kubermatic workshop](/static/kubermatic-workshop_anker_blog-post.png) [Into the ServiceMesh](https://it.t.hubspotemail.net/e2t/tc/VXc7-r5PpDPqW5-KGl233R13ZW61z83B4wng6wN8Zqh7L3lHNGV1-WJV7CgX2CW8kWjcB2z48n-W5JkQ-_4-t7KQW430tmm8jXdV6W2NWMH-3GLcYSW4TPlGr9g-VWQW8rB-F72T8Gt2VX4NQP2L2bVhW7zPmLm2Rfx0pW2hwxPy3NZknNW558Sr326S1nKW9kNprN4k0pq2W8_pbpB7G6K1dW1YhFvv6pmyvwW88cw9L8wpXsgW8_R0Pm69VHVhV4h_kP8m5vf4W79_DdY8G4qjkVg9NM_7qwLx1W4M5B9C5S4tV9W4BW33_9kcPrJW3pJnFk5QZ2V-W2B8qDg1m0Bly3mQr1) [📢](https://lh5.googleusercontent.com/jC50ytZ_4EKsXzja1Th5xRj0-K4aHlEjJXpcVuCWokppPMxeQBEPR2Unn2IL87xpUH990pZCwpH3QnGekKl3sNooM5DuCZhuwpHzyeV74UF7ta217onJQGsWya-CQlsCSLw21mJH) Hubert Ströbitzer, Kubernetes Consultant at Kubermatic [📆](https://lh6.googleusercontent.com/Wy0SUrXdPqoAKCWe1v2zXUg5VujeMq-CGkvKKC5wjViqM2qtBy6DDb64Pds4iiLSoX8m4Hmj_JsLJBAieNNOgXIFGNb3ZiKtfnqkI-6WyW-uA4NJE_TPSLNKNCsfi6dAxJzi1BGd) Thursday, September 23 at 9:00 AM CEST **[💡](https://lh6.googleusercontent.com/VZxgifd4tcoFQvc6zr44Za2oHW8HZgnPO2uMs3sSCvOyMdWUeDQ3HTsrcIIZ3WenqEGkYr0KS6kR57xtuV_ncKFUbwuHleXKoy6mIz0XCx5ffnvzKQ4KtfBeeimew2WVeEqALbR6)** #Intermediate #Developers #Online ⠀ This training session will accelerate your understanding of service mesh and provide practical instructions for getting more out of your Kubernetes cluster. As well as general knowledge on service meshes we will also provide deep insights on how to get things done with Istio. #### **[Sign Up](https://cxwn804.na1.hubspotlinks.com/Btc/LW+113/cxWn804/VWcp5-3KrWw_W90DYR18ZXG_bW8LzBkh4wq7smN880g3G3lSbNV1-WJV7CgD13W79N_5D4bzZB_Vzqp3t6YVtwjW1vzD-b7PVhyBVDtZ388g_gVRW6M37182wKxpGW8c-V0p6G9KflW9blm556grDGrVyPvbk6kPr6bN4zWkKxcHcQVW1217g72rj2_XW8TDR4X6ShhyRW8NYtZ88lPSDFW4Pln6G1vwhXCW5p9Q1t53zBpYW1FrtWp2xn1MWW5Lrs243GWph0W4Bcn1Z1jLc6gW6sFh7L15FL27W3M0NwY9357BnW5M-bvv95Jrc6W3RsLpq86BRsNW5bZmls8nsFFh3g6b1)** ⠀ ![Crab - after show event](/static/aftershow-event_crab_blog-post.png) ”Shaken, not stirred!” or how do you prefer your favourite cocktail? Time to find out! For this year’s online after show event, we‘ve come up with something special to end the first day of the conference in a fun and interactive way. We’re inviting you to join us on **September 21 at 6:30 PM CEST** for an **online cocktail course** to learn, under the guidance of trained bartenders, everything you need to know to **mix your very own cocktail**, as well as how to make a lasting impression at your next party with all of your newly-acquired knowledge, tricks & tips;) Further instructions on how to join and what ingredients to buy will be provided once you’ve signed up. If you want to attend, please send us a short email to [marketing@kubermatic.com](mailto:marketing@kubermatic.com) so that we can put you on the list. *P.S.: Attendance is limited to 50 people – so be quick and save your seat!* ## **Want to Know More?** Check out our [website](https://cxwn804.na1.hubspotlinks.com/Btc/LW+113/cxWn804/VWcp5-3KrWw_W90DYR18ZXG_bW8LzBkh4wq7smN880g333lSb9V1-WJV7CgFRgW7klymB5Bv9dgW6tDR5S55bYnLW1HSHcx6f74Q7W2N_CMF11vH4pW8QdJkZ54kDscW3VQMbr5jWmzGW5JkB8773W74fVz8x5s5KNsc3N1R6mQdwhtXfW1SK3GY5yCWrdV9w8gT7vtMmLW5P-N5G1qgb6xW6z-yGG5tf0jmN7S5t4NgwTm6W4W4vW41ls1chW7-slG92n3vXBW6xBykP4rWDS3W2V0Bx55hjXfz2nM1), follow us on [twitter](https://cxwn804.na1.hubspotlinks.com/Btc/LW+113/cxWn804/VWcp5-3KrWw_W90DYR18ZXG_bW8LzBkh4wq7smN880g333lSb9V1-WJV7CgFSpW8SrJmQ27ZqZ3W8TpxCL12xNy0W4kHsd26wdLrxW4VYx9j5fjdl6W5PCFYw1Fn1jqW5YfWBN3PZHsLW22CVmD1kqzrYW2gsc4g3hSJGDVt2skw3NnRnyW7wMn3h5Qth6MW5BjZQb5dkKh9W3tHfkS1_DWdFW4GDzm856mqymW55jL918CPKQ0N523qm1_vRyvW94jkjn3hWXFCVQvjQ85JgJH4W1HSgGW5WD8lw3lKk1) or send us an [email](mailto:info@kubermatic.com). --- ## A Framework for Kubernetes Incident Response - **URL:** https://www.kubermatic.com/blog/a-framework-for-kubernetes-incident-response/ - **Date:** 2026-05-07 - **Description:** Understand the basics of Kubernetes incident response and how to communicate with incident responders about what is happening in a containerized environment. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Sascha Haase Kubernetes is used by organizations of all sizes to run production, mission critical applications. This fact is well known by attackers, who realize Kubernetes clusters are the “crown jewels” of an IT environment. Compromising a cluster grants an attacker access to sensitive data, control over business applications, and the ability to abuse an organization’s computing resources for cryptomining or criminal activity.  Kubernetes security is a broad topic - in this article I’ll focus on one critical aspect: incident response. [Kubernetes clusters and pods](https://spot.io/resources/kubernetes-architecture/kubernetes-pod-why-where-and-how/) are operated by DevOps engineers and developers. They are the first ones to see the warning signs of an attack. Will they know how to recognize an attack and how to escalate it to security teams? Do they have a common language to communicate with incident responders about what is happening in a containerized environment? Read on to understand the basics of Kubernetes incident response and how to create this common language between DevOps, software engineers, and the [security operations center (SOC)](https://www.exabeam.com/security-operations-center/security-operations-center-a-quick-start-guide/). ## **Incident Response Basics** [An incident response plan (IRP)](https://www.cynet.com/incident-response/incident-response-plan/) is a documented and systematic process that outlines how the organization acts during a security incident. A solid IRP can significantly reduce the amount of damage caused to the organization during a disaster. It helps standardize response across the organization, ensuring each role knows exactly how to act in a timely and appropriate manner. To ensure the success of an IRP, all relevant stakeholders must know their responsibilities and agree to the plan. They should also be ready to coordinate the efforts around the IRP when attacks occur. IRP stakeholders usually include members of several teams, including legal, operations, security, PR, customers, partners, developers, and executive management. Here are several benefits of a solid incident response plan: 1. **Be ready for emergencies** - security events occur without warning. It is critical to create a process in advance. 2. **Coordinate your efforts** - organizations can find it difficult to keep all stakeholders in the loop when a crisis strikes. An IRP can standardize communication, ensuring everyone is on the same page and well informed. 3. **Expose security gaps** - many organizations typically have limited technical maturity or limited staff. An IRP can help reveal obvious security gaps related to tooling or process, ensuring the organization can address the issues before a crisis occurs. 4. **Practice your response** - an IRP helps create clear and repeatable processes that relevant stakeholders can follow during every incident. This improves the coordination and effectiveness of your response over time. ## **Recent Kubernetes Security Breaches** Studying the details of real life security breaches can help you prepare your organization’s incident response strategy. #### **Docker Hub Attack** Kubernetes environments are highly dynamic, making it difficult to pinpoint the source of an attack. In the famous Docker Hub attack, attackers planted malicious container images inside the Docker Hub image repository. Anyone using these images was cryptojacked. This means that users unwittingly deployed cryptocurrency miners in the form of Docker containers, which then used computing resources to mine cryptocurrency for attackers. #### **Tesla Rogue Pod Attack** Cryptocurrencies are soaring in value, and the cloud's unlimited computing resources make resource hijacking more profitable than stealing information. Automaker Tesla was one of the earliest victims of cryptojacking, when a Kubernetes cluster was compromised due to an administrative console not being password protected.  The issue was discovered by RedLock Cloud Security Intelligence and disclosed in a report that informed the public of the issue - a misconfiguration helped attackers to gain access to Tesla's AWS S3 bucket, where credentials were stored. These credentials were used to run a script on a Kubernetes pod that performed illicit cryptomining. #### **Jenkins Croptomining Exploit** Hackers exploited a Jenkins vulnerability to cryptomine approximately $3.5 million USD (10,800 coins in the Monero cryptocurrency), within 18 months. In addition to exploiting vulnerable personal computers running Jenkins and Windows machines, this attack evolved to targeting Jenkins CI servers. This is a recent update of the malware, which continues to update itself and change the mine pool in order to evade detection. ## **Security Controls and Forensic Analysis for Kubernetes** #### **Preparing an Incident Response Plan** An IRP is critical to ensure incidents are efficiently managed. A solid plan can help your organization to effectively recover from incidents, as well as prevent future incidents. Here are several important phases every IRP should include: * **Identification** - incidents should be detected as accurately and early as possible. This is key to ensure effective incident response and management. This phase involves monitoring security events on the Kubernetes control plane and worker nodes, detecting incidents, and reporting on potential risks. * **Coordination** - once incidents are reported, DevOps teams must coordinate with SOC analysts to evaluate each event and ascertain if it is a real security incident. After analyzing the data, they initiate an incident response process. * **Resolution** - teams investigate the main cause of the reported incident. Responders strive to limit the impact and resolve all immediate risks. While remediating, DevOps and security teams implement necessary fixes and recover any affected data, services, and systems. A critical decision at this stage is whether to shut down the cluster, or known infected nodes, until the threat is eradicated. * **Continuous improvement** - after each new incident, DevOps teams and SOC responders learn new insights. Using this information, teams can fine tune Kubernetes clusters, implement new security measures, and improve the incident response process itself. #### **Make It Clear When to Escalate** Before launching your code into a production cluster, it's important to understand your application and infrastructure security model. You should also clearly define what is considered a security incident that requires a response from your DevOps team. Additionally, you should set guidelines that explain when the in-house team should respond and when they should call in external experts. Incident response, for example, can start when the ops team submits a potential event and classifies it as a security incident. The ops team then assigns the incident to the relevant security team member.  Your IRP defines when outside security experts should be called as well as how teams are engaged. Developing these processes is critical to ensuring effective incident response, as cluster administrators are the first to discover and identify security issues. #### **Container Forensics** After implementing the necessary security mechanisms for your Kubernetes workloads and drafting an IRP, you should make sure that all roles involved in forensic analysis have access to the necessary information. Here are several important data sources required for container forensics: **Logs**   Logs are critical for forensic investigations. For example, Kubernetes logs, cloud infrastructure logs, application logs, and audit logs. You should also analyze operating system logs, such as network connections, SSH sessions, processes, user logins, and executions. **Node snapshots**  You can take snapshots of a node’s disk. As needed, you might want to shift other workloads elsewhere and quarantine your nodes, then run additional analyses. During this time, you should be able to identify affected nodes and any attached disks.  Be sure to create a duplicate of disks while they are online and send the duplicated images for analysis. You should also use the Docker explorer tool, and compare the differences in binaries on your disk snapshots. **Container visibility tools** Responders, whether they are part of a DevOps or other security analysts, should use the tools available to them when they work with Kubernetes and Docker. For example, the Docker statistics API can help responders obtain system metrics, which are highly useful for understanding how systems are impacted by its container load. Container visibility tools can help responders detect activities occuring in the system and understand several aspects of these behaviors. For example, understanding if the files are expected or unexpected. The tool can also help you understand how to get real-time information without actually logging in, and how to remotely gather information from multiple sources. ## **Conclusion** In this article I explained the basics of Kubernetes incident response, and presented three essential components that will help your organization respond to and successfully contain an attack: * **Preparing an incident response plan** - defining the process of identifying an incident, coordinating with all stakeholders, resolving the incident, and making changes to the environment to prevent future incidents. * **Make it clear when to escalate** - give DevOps teams the tools and knowledge they need to identify warning signs of a cybersecurity incident, and clear thresholds for escalating issues to the SOC. * **Container forensics** - ensure you have logs of all security-relevant events in your environment, and the ability to quickly access these logs and perform forensic investigation in case of an attack. I hope this will be of help as you build a coordinated effort to secure your Kubernetes environment. --- ## Kubermatic News for July 2021 - **URL:** https://www.kubermatic.com/blog/kubermatic-news-for-july-2021/ - **Date:** 2026-05-07 - **Description:** Learn why having a multi-cloud strategy is a clear business imperative and sign up for ContainerDays Hybrid 2021. - **Categories:** Company - **Tags:** Announcements - **Authors:** Sebastian Scheele “You’re crazy if you don’t start in the cloud; you’re crazy if you stay on it.” The recent article [The Cost of Cloud, a Trillion Dollar Paradox](https://it.t.hubspotemail.net/e2t/tc/VWbZJg3jPBW3W3xqpQJ4KrWBJW1sXT7r4vvNn3MtGxltcdSnfV9V4KD7CgQnzW1mlcrb8rtMP7W4zVSHR6Wcrg7VyFGKg248TzVN5TH0Z14CYfVW45JsRb4Xg44rW4YbfRW5D3lJqW2Ys7hx4gjcrjVQg-yG46L4WvW5nMrJ71nYJGnM1hBGzPHL4-W65NqKl3pNC3NW2tQX9R6nj-N1W6nL8K-5hxsT1W8Q7R-36x2J-rW2W3wpq8bXSMwN3Rsl2wT4xrJW9030RY5Fy3-cMT1vWMDyy5lW7cgW6s1l5XNSW750k0Z3rhx5vW6wN2D64B6881W136h306mVgDlW22_vtm6jPffpW7Msd3K8Tc99QN9fL2Q-QJ5qXW9bvPhF89yXrCW3qBb8T35frGQVMwBFt2YYK9cN5vlQ7kJYlQyVgfPXR1-HVslW90zbmJ6m6dmJN31Bxj6p5Z40W2F9cgJ6MKGfjW59Tbgl7tD2dGVR1MFh674nx5W1fzrss1qSq1PW8VR_Sp64QYW-VKPXQL8l-216W5Z1c-K8pSRVqV2pp544kf_jBV7kCgG66FF7LW2_6k8l1HwCqFW2M49m_6xLGlKW7QMSxr4pNfXzN26sc4HDZTnfW98qmx31Q5WC2W2nTxML2t-G39W6yy0m020SVHZW2QrvLr4DXwnwW5VFRbK4Th2NYW5FB7gd5H6w8zW8RkljS6kZXs0W5dF0SF855WVvW8mdc_V2g2_qKW2L8x2z2XTD9MW6SLWzW7PPCrlW47N0--7HCqt1W2ZsH1q3S8tw5W8xCs_P8y-XJkW47zpKt8qXWCQN2lfW84gH7jZW2p_JxF3wz1D1W7mwf444djnlbW8JFjlX8RxrZVVQTmv566t0nkW3v5cXs58H1gsW5xQYn11xNryMVgFvvx65BjDFW4xJ7233ybxf-W1Lxw_h39L_xmW4J-Wrz1g9wSqW6jf7YW2rYyZkW5ZGWGW6y8Q6gW2FBZWt3BfpqJW6L6ZVL1mcR9yW3MfcD98vwrsSW7DW5GP8vZX7_N2Ttpp3NkP8xW7X-Mfh75KJymW3hqWMy5PbbXnW6llmJb7Yn5RbN8bg5vTl2rnJW7y-Dcc6DHHhDN1wSX1YLbVfL3gph1) by Andreesen Horowitz sums up the paradox of the cloud quite well: While cloud is cheaper and better early on, it loses a good deal of its cost/benefit ratio as a company evolves and scales, by “locking up hundreds of billions of market cap”. There’s no doubt that cloud has proven itself as the go-to platform to optimize for innovation, agility, and growth. **It’s very business critical, however, to consider its long term implications and the broader impact on margins.** So how do we address this dilemma without surrendering to increasing costs or compromising on our digital competitiveness? Unquestionably, **implementing a multi-cloud strategy is the most important step to maximize cost savings**. The flexibility of using multiple public cloud resources can achieve tremendous cost efficiencies: With multi-cloud environments, businesses can deliver **quality products and services with low overhead.** **Managing those services and their associated applications becomes easier and more cost effective**, especially when paired with the **right multi-cloud tooling**. At Kubermatic, we are convinced that multi-cloud is not a nice to have; it’s a **clear business imperative** for all larger organizations. It’s only a viable solution, however, if  **managing services across diverse infrastructures is simple and safe**. That’s why we are constantly working on just that; solutions to automate every layer of multi-cloud management. Do you need help designing and implementing the right multi-cloud strategy for your company? [Our team of cloud native experts](https://it.t.hubspotemail.net/e2t/tc/VWbZJg3jPBW3W3xqpQJ4KrWBJW1sXT7r4vvNn3MtGxlN3lGmQV1-WJV7Cg-mTW6mGxRg1pdlcyN7zQHmS3G8c7W48qTQP51BCw3W2Vk1KZ2YxjHcVqMgTY635MlVW6b4vV-89_047W2MKPbB68zprZW60w18m1G8lqNW2dHntS4Drh-2W8nzP0X432jhNW8Srv9Q8fyYxBW5qJm0658MfzTW1Y_fFp4318P4W1-2vyt8gLM2pW2m1bRK1NvJbXW8zhbyt3MNWFFN7jhkz7gMyHSW4CwmFX7yQ6CyVfzDjL8rNsb1W5PJPj471ChFlW4fxdPG7z1M_nW3RGkVv8jDKdl3f6k1) will be happy to help you succeed in this endeavour. **Here come our July news and higlights. We hope you enjoy them.** ## PRODUCT UPDATES ![A woman with tablet in her hands](/static/kubermatic-news-july-product-updates.jpg) ## **Submit Your Review on Capterra and Get Your $20 Gift Card** Have you already played around with Kubermatic Kubernetes Platform (KKP) to automate your Kubernetes clusters anywhere? Great! What would be even better is if you would write a review for KKP on Capterra. The first 100 reviewers get a $20 gift card – so, better hurry;) **[Get Your $20 Gift Card](https://review.capterra.com/Feedback-Kubermatic-Kubernetes-Platform-199419-3186045353?utm_medium=email&_hsmi=2&_hsenc=p2ANqtz--shK0fUMnmYHe8OloqjY80lwvz4sRaIwp87BtTisZMLhBf4poL3Y9LnemSpb2wRiOyKhnu5RNk4QwSHr9bhg-PdMAkbA&utm_content=2&utm_source=hs_email)** ## KUBERMATIC BLOG ![A cup of coffee, notebook, and keyboard on the table](/static/kubermatic-news-july-kubermatic-blog.jpg) * [How to Manage Multi-Cluster Kubernetes with Operators](https://it.t.hubspotemail.net/e2t/tc/VWbZJg3jPBW3W3xqpQJ4KrWBJW1sXT7r4vvNn3MtGxmG3lGnJV1-WJV7CgVftW5j7-qs5Hb-bdW6hp3NK5bVlXCW2YmRmS4q_X9xW8FD5Mn7tZl9pW2dGFS04PsYVhVVYSZJ5HN7CRVfcCRN5xzG_TW3nZdTf1z4HjvW3fb_sz4MgBNhW70HlZd5s-lvtW361tJ_83MR2sW4bHmtq45-hh9W2qJ9bf6S1MqBW9fx35T80xBFfW7s59qH25PV83W4yy5zv4WQ9CHW29bVTP7bnKj_W3xYc3y5GLNHFW2htj471JSWvfN4DrZwFPc6gmW4J3n_62qDCB7W2HdXVW7Jfb13W4B-cvc7Ms_ljW7nPRxy6Nyk69W69tQsG94n_VJN8chlf8wd2CTW4qvKty4VPJ-XN7mtRpLJvkvD3bD81) * [Combating Kube Chaos Without Losing Your Sanity](https://it.t.hubspotemail.net/e2t/tc/VWbZJg3jPBW3W3xqpQJ4KrWBJW1sXT7r4vvNn3MtGxmm3lGnpV1-WJV7CgYp-W1CG0-g8Jr7mBVJm3M247w_wbW92LWbW1jrWypN43QJpDhBn_ZVZFZYq3YFbmKW9lpR1S7CfjTfW548FzR4wrW2kN66G6P5vkQxVW6kNNvx59t9hTW2yNZ_53yTdVVW7F1gfV7MJ0NmW95_p591KBCZvW9fbPcZ8jhqv9W3MCQ932WWDH8W3DhpyV8ZvXtwN2LX2zWy59gMW1lXZBr5BdQ_WW1XjRJK8WDvWjW2pbZCB7QjYtzN5x4Fq1-381xN1_pf8MZYtQBW5PGcZl1JqHZrW4rLmGG42bQFHVbG6b622QwDSW1gNrK93TVlSDW4Kbt8z1L0dJ63ptn1) * [Automate Your Multi-Cloud Services With KubeCarrier](https://it.t.hubspotemail.net/e2t/tc/VWbZJg3jPBW3W3xqpQJ4KrWBJW1sXT7r4vvNn3MtGxm33lGn5V1-WJV7CgC5ZN5n_5yKn53bBW4P2XSW98qBbyW1qqyrB5yHJjrV2fDDF6kwqz7W69KgKm5VH4D4VWscB22LWh3MW7lf2Kz2PVyf8N418PXtjRp3gW6SXhw36d7HXpW2blm2D4wzrgfW2jjCZ55w-8jmVyKmkW8lRBvDW8M_F0T1HPNx1VLtrBw3j7RQ4W3BPCVc8wTXn2W67cF0p5hgYhpW7mqvg_5FHP4CVnCKsh3yylffW560Yqy5vFYbzMlKVXVBD_JQW4kSHGv5rHmgcN5HmmBtrKCqNW7SB0Lf8N5F_9W1fm99-5hNj6237661) **[Discover our blog ](https://www.kubermatic.com/blog/?utm_medium=email&_hsmi=143810148&_hsenc=p2ANqtz-9bgbmwKxTJxmXMqAWIAZciou7HJDHb54VXHPdm9YBSBzzqQUOcTkX7yR0D3qe3RQo4xjQRvbLWjxOTXEe2_OoThMk64Q&utm_content=143810148&utm_source=hs_email)** ## KUBERMATIC RESOURCES ![Library inside with books shelves](/static/kubermatic-news-july-resource.jpg) **\#1 Demo** Automate operations of hundreds of Kubernetes clusters across any hybrid or multi-cloud environment. Kubermatic Kubernetes Platform (KKP) provides you with standardized cluster installations, centralized compliance, full lifecycle management and business critical support. [Automate Your Clusters Across Multi-Cloud with KKP](https://it.t.hubspotemail.net/e2t/tc/VWbZJg3jPBW3W3xqpQJ4KrWBJW1sXT7r4vvNn3MtGxmG3lGnJV1-WJV7CgTq-W2xSnn88ywVVGW22YM-g4sMX4FW5n4PkS7MjWK3W4Nd-tr2Wqcl-W4W16Gm8ycVmJW8Yvtml7H8ykmW13gmlY2_Gh-zW2MVcC18DcBxCW1sFF9C7QbzqRW31r73n4pnJsmVsN0wR2j8hnZW2hFDX22Z3JhfW4FGBK9773NxzW88mt385QlYFPW6nbk3k3h0hKqW37W5043FPBPcW2l13wh9j19CbW24Wfkm8byGGfN6_l9LDhGXcwN2zpxycZtSQPN8LJYNwM7dymN7Ts9CLJxqXmW4LJQx-8N07_ZW6M3vSq4ZLnVRW5XlsrT2_965pW65CwP39k3S2jW2FCtGM6zQ48TW8fWjtS2wJDX_31zB1) **\#2 Checklist** Kubernetes is very powerful, but the path to its adoption isn’t always easy. To help you determine quickly and easily if you are ready to run Kubernetes in production, we’ve created a very handy and comprehensive checklist.  [The Ultimate Checklist for Running Kubernetes in Production](https://it.t.hubspotemail.net/e2t/tc/VWbZJg3jPBW3W3xqpQJ4KrWBJW1sXT7r4vvNn3MtGxmG3lGnJV1-WJV7CgQppW8z0kJP8WVf33W3pYc8621dhgMW4Cxy6P1gmhtvN5ZdywpZdDJpW1gg9CC3H00FJW7syv5l6byybnN51_43vb09VkVwRpx-5DnfxlW3rLwHL3k_G57W1D0WVn7zBtWkW2JpCFB71b2yfVDWtTl6NffpVN2QW-3jGy5KqW1PwKf55TgqyZW4fdnHp120_3kW93QwxQ7gfpkvW7F-QND6qh-B8W6t9QFr79CH7gW2Y8cVm5M0Bz2VRhl951_rHsHW6F6_Z64br5V3W4p5gBt3BCTT2W4-sppn2fc8MBVwhbTp5S-dfhW6-3LLW8RdCVSW8dJ1Bv41yNF-W4R0FW_4GP7rCW37v5kR8dd38l3gLD1) **\#3 Webinar Recording** Complex application services consisting of numerous interconnected components can benefit from deployment in multiple Kubernetes clusters. However, this approach has some challenges. In this recording, you’ll see what this type of deployment looks like, with the help of KubeCarrier. [How to Deploy Multi-cluster Services With Operators and KubeCarrier?](https://it.t.hubspotemail.net/e2t/tc/VWbZJg3jPBW3W3xqpQJ4KrWBJW1sXT7r4vvNn3MtGxmZ3lGn_V1-WJV7CgDM9W8lZHJf7kk4z2W7hq7TH5rT5mQW3G3l3y2h8ZZLW83jm4h11QC-LW2j4CF93V1ttkW7DQSFt5zLbrWW3qzwVk4vmqYJN25_d5dLJW6TW6_ByFX4Rf6w7W8B-7YX4J7qJPN33mMjyz-YLdVSfn7r4b77b2W6Wp7153Tqnx2N8682ycd3cPLW8PsGWy6RfcGXW45M9bq6Jk8NLN1Jcrq58KnNbW8xhVCd2_LrGBV9-TQY1YSGtwW2tlpNS8DzpTkW6rZqpx1rTRmPW6JyTV-8WlBr_W1Z-x8r3RhnwlW8PHcK-1cz35qW74ZkmH8Px9LrW14LkCw7SYfSPW91HXkv1zsqwRW2TVBwz739BsqW43TXZC1Nhp-PW2lQYjV1-MhRd342l1) **[Browse Our Resource Library](https://www.kubermatic.com/resources/?utm_medium=email&_hsmi=143810148&_hsenc=p2ANqtz-_rZo2Tx_97FLA40NtNCT_Aj07r3xdvIlKDRl7rUZESL9Ct923zNqqT7GXdpmb1Asf-V9Q65FJ6G0lFSBdHa77JxPDFPg&utm_content=143810148&utm_source=hs_email)** ## UPCOMING EVENTS ![A neon sign with text "This is the sign you've been looking for"](/static/kubermatic-news-july-upcoming-events.jpg) ## **ContainerDays Hybrid 2021** Whether you're just starting your cloud native journey or already have your initial projects up and running, [ContainerDays](https://it.t.hubspotemail.net/e2t/tc/VWbZJg3jPBW3W3xqpQJ4KrWBJW1sXT7r4vvNn3MtGxlNh9YnXVfR9K_7CgXH9W5kr3f_4l6cTBW7YZVgs1ppf0wN40dlv-h6z7DW3mfwpV2F8z2bW8bZ1rV4SCss6W66Ljrz87QN7wW4-ZwVT59y4Q1W8L9B8p63_Mb6N8v7qfB-4kbPW3tp_Qy6-zWpyW2B8J8v11ndkCW6nhJ-12GrSm2W6rHjRN4DRdXDW5gXWhC5ZsbkcN399-9jcRhFmW63nNC370r-LVW4RYbtb96JdVDW10H2pF8ysJjVW2Cchzm6cLTwjW2ZGG2q7KRJ0SW7Ggs1w95ybdbW7cY5Hd886PLWW873j6P1xpy8yW2QK55G2X2xrMW3c24Bv3700trW3TSBTB7hwCDRW6K-fcT4Wc6k0W5l7f7F976sx7W6lwbR-42qQs1W1cVRQX1K0J-hW2hC5pT6mKjPdW3HZK9r8nzLDFV_0mmM3KS3QjW8vcK9w7c-7YjW5qpWGP6mwNSKW6dZHYP8xN8xyW8fN7fH2xyjVSV4lc5j4vvX0hW8NZZ1d8JHSK3W38fMW74Q-vmhW7Ks5x28y7FdmW395DtC6RgG1cVFlCvt6wxGg4N3TpwjqkJhqcW6wGsSV639BzgW2NF-bP1j_QS8W6w_M3Z8NMzwMW3HW4P25lQF-ZVfZM-46KtzBmW6kp4RT3fStvxW7kkSfr4_QgdQW6S9LQk4Qx6D5W9jnB5Q4XZD4LW402MYX3YH3_JW2Wvngq15MmkPW5dk6NJ1rRSlSW8FXJ-c1TBNS4N6SdjgnNV_06W5sQyPk9cF6XLVtC8Sj24Y-WCW3Ls0602NDBcGW7qC58_6fbWG8W1PGVdQ2NrTxjW2p3-WT5kTXvHW7yBM3c8_Mh-hW1-0pXY8wk7mGW73WMNC2DNnTwW8-f_X43bfQgWW7-db8M7vqMsrVlP9G54nGQ0GW6TNs3n5BDN7pW4t7WRZ3GBJjtN4zp476vpcWGW89nGr541pbltVQWRdV2RMvMbN73LwHwnxpPYVbb1xj5RNWbKW5v5PQc2gnm7rW2nGg3d3vs0y1N5kX-Q1zc2NJW7x7lCn5lWKYpN6zYWg-PbqDmW4TSkVR8Xl3j5VFglXQ29VGPfW2Kz9071cy_r2N8LcztsXl_g6W6n1Whn4zwsmNW8C_svS20xVyjW8m1Yv25pgmMTVBWFjp5-Tg0FVMgzyl5jWsS9W2xqtpd462sg7W3t6-CJ1QWD3CW66jQHG6TgRpPW7Bq1Vw6Rd7fSN3dZb7-28H8yW6wXN056cSXKxMWycPz2h6nRW1rzSpl7N8ldNW2r9yj34LzB5nV_NQDf7Bc_HfW2c6jRL1rtJk9W4tBlYF8fDb29W2vN31T2XyjfzW7kksSQ3rjBWzW95xV4Z343NmBW83FG605vBXQ3Vqz3GB6XCfwxW4g1ztB9lDbsQW19ZwtP1JGz-dW6PgG_z8rdzBtW91JJ_L3RSCpWW73YN_b4xdt2wW9bbYMF1t29fWW7kNrQd4LBsH0W49wxYn8K2vr1W8yb2VR5vf14tW71G1nY4gc3RT3cPR1) is the place to be to exchange with other cloud native enthusiasts from around the world. Join us on **September 21-23,** virtually or in the beautiful city of Hamburg. **[Get Your Ticket](https://www.containerdays.io/tickets/?utm_medium=email&_hsmi=143810148&_hsenc=p2ANqtz-_ijGa4XBjBmTVcPCXfLH72yEevKg3fQeiSQvuN9E3Im9gF21wk2xteePryvmDJsCt5WAqbAmKlMR6sSyV83wuzo7ftlg&utm_content=143810148&utm_source=hs_email)** ## **CNCF On-demand Webinar** For a more comprehensive look into the world of managing services and applications on multi-cloud, sign up for our CNCF on-demand webinar *[How to Manage Thousands of Kubernetes Applications With Minimum Effort Using KubeCarrier](https://it.t.hubspotemail.net/e2t/tc/VWbZJg3jPBW3W3xqpQJ4KrWBJW1sXT7r4vvNn3MtGxlt3lGmwV1-WJV7CgY1sW14LVX25stPzMW3CtN_k4mMXNrW66sJJ17r-ML6W7H0jQH5D2tMtW7j047f1HmtRJW4BpdJ012pNRLN8fvz59k8vH5W8VgNZj4PvlVZW4hzRHs5vwZbJW1f0NGB2-J1KSW1nnN2t7HY8D4W6Y_QDs3v12l8VZ9Xv32rk6KhV1V3yk3Rk9zTW5YthPF13410vVhjMv48v7GPKN6zHn9zhzqzMW2f65y26bL6mHW2Tk6005ssvlnW4LlXzV92Kgmq3lsL1)* hosted by our Software Engineer Jiacheng Xu on August 19 at 12 PM CEST. **[Sign Up](https://community.cncf.io/events/details/cncf-cncf-online-programs-presents-cncf-on-demand-webinar-manage-thousands-of-k8s-applications-with-minimal-efforts-using-kubecarrier/?utm_medium=email&_hsmi=143810148&_hsenc=p2ANqtz--6HTPWRLpQepefrYQ0Szr2yBqNG-oPxIbQZVV_kiWOJrJeAEu6DAwaYbZuFcbRCEgPmx1285J7oWwSfAauErnw7iXgQA&utm_content=143810148&utm_source=hs_email)** ## Want to Know More? Check out our [website](https://it.t.hubspotemail.net/e2t/tc/VVzQSB29c75QMb_QjDwVWlVV5XFwB4tbF2bN8kT_z_3lGmcV1-WJV7CgCt2W3_1vQX5LwZ9WM_t03Szz-Y1W8F70gD7fzl86W1klGzm7Wn5VlW6C-K878xXGfbW4N8Q9T4tlhPNW4xPpjR4wTTn2N96rk7R5dnR7W4vngm46PpTJ2W3QG4GZ5YL60XW3jDQV-7_J0_hW8HCyfT5Fv2J_N7Nv547gKGXWW377lbc43RVDNW15pSPk92X1f1W3gpGtL7KHP29W9kl2xR31s9h3W8fLphY2qsPTh32KB1), follow us on [twitter](https://it.t.hubspotemail.net/e2t/tc/VVzQSB29c75QMb_QjDwVWlVV5XFwB4tbF2bN8kT_z_3lGmcV1-WJV7CgzPhMRkM7HXf_h8W5BCQcw6S3Yj3W4myYs-4TgytzW3pz2TX8_kbvwW6rN_vv7hNnl5W98pNhh48kGByW8c88tw25jBZSW6h2vZD7NShkwN6YBsWWNP4SHVNhPZZ99YDXqN26jpr6VcqfNV_SGcj3Nk7YbW87sfjN31tVv7N62NMRW_P7hSW8pvFdF18BtPqW5xyp4871ly1XW7cPslz87-QZnW6HWpVV42xjxq37kj1) or send us an email. --- ## StatefulSets: An Introduction - **URL:** https://www.kubermatic.com/blog/keeping-the-state-of-apps-6-introduction-to-statefulsets/ - **Date:** 2026-04-30 - **Description:** Learn more about another persistent data object referred to as a StatefulSet and get some hands-on practice on the functionalities of this object. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Seyi Ewegbemi In previous parts of this series, we walked you through [StorageClass](/blog/keeping-the-state-of-apps-5-introduction-to-storage-classes/) as one of the Kubernetes objects for data persistence. Let’s now look at another persistent data object referred to as a StatefulSet. We’ll cover the topics below and some hands-on practice to show you the functionalities of this object. * What is a StatefulSet? * How do StatefulSets differ from Deployments? * How to specify Pods easily inside of StatefulSets? * How to manage Volumes in a Pod? * Why use a Service for StatefulSets? ## What Is a StatefulSet? A StatefulSet is a Kubernetes object used to deploy and manage stateful applications. Stateless applications, you may recall from a prior part of this series, are deployed using various Kubernetes objects like [Deployments](/blog/introduction-to-kubernetes-deployment/) and [Pods](/blog/introduction-to-pods/). We then covered [data persistence](/blog/keeping-the-state-of-apps-4-persistentvolumes-and-persistentvolum/) to manage Stateful applications. So, what are stateful and stateless applications?  **Stateful Applications** are applications that are mindful of their past and present state. In a nutshell, the applications that monitor or keep track of their state. They store data using persistent storage and read the data later to survive service breakdown or restarts. Database applications like MySQL and MongoDB are examples of stateful applications. On the other hand, **Stateless Applications** are applications that do not monitor any of their states. They neither store nor read data from any storage; they are basically a one-time request and feedback process. When a stateless application’s current session is down, interrupted or deleted, the new session will start with a clean slate, without referring to past events or processes. Examples include the Nginx web application and Tomcat web server. ## How do StatefulSets differ from Deployments? ### StatefulSets vs Deployments: | StatefulSet | Deployment | | - | - | | Used to deploy stateful applications. | Used to deploy stateless applications. | | Pods created by Statefulsets have unique names which remain constant across application rescheduling. | Pods created by Deployment have dynamic, random names and numbers that change across application rescheduling. | | Its Pods are created in sequential order and deleted in reverse, sequential order. | Its Pods are created and deleted randomly. | | Its Pods are not interchangeable and maitain their identities after restarts. | Its Pods are interchangeable and do not maintain their identities after restarts | | It does not allow shared volume. Thus, each Pod replica has its own sticky Volume and PersistentVolumeClaim. | It allows shared volume via Volume and PesistentVolumeClaim across all of the Pod replicas. | | Replication is complex. | Replication is easier. | So, if you need a: * unique and ordered deployment and scaling, * distinct and stable network identities, * steady and persistent storage across all application scheduling and rescheduling, then, you would use StatefulSet instead of Deployment. ## How to Specify Pods Inside StatefulSets Pods in a StatefulSet have a sticky and unique network identity. They are specified inside a StatefulSet by declaring a **“replicas”** field as a child of a **“spec”** property in the StatefulSet YAML manifest. The desired number of Pod depends on the **“replicas”** value specified in the manifest file. The configuration will look like this: ```yaml spec:   selector:     matchLabels:       app: service-label  ## This must be the same as the Pod template and service labels      replicas: 3   ## It is 1 by default. The value specified here will determine the number of replicated Pods the StatefulSet will create; in this case, it will be 3 Pods.  ``` ## How to Manage volumes in the specified Pod in a StatefulSet In the last part of this series, we [created a Pod](/blog/keeping-the-state-of-apps-4-persistentvolumes-and-persistentvolum/) that consumes storage as a volume using PVC. A **“persistentVolumeClaim”** field was declared in the manifest YAML file which gave the Pod access to the PersistentVolume that the PVC is bound to. In the case of a StatefulSet, a different property will be used, namely  **“volumeClaimTemplates”**. The **template name**, **accessModes**, **storageClassName** and **storage** **requests** fields are declared under this property.  The Pods access the storage through this section and then mount it into the Pods’ containers using the **“volumeMounts”** field. The claim and mount configuration in a StatefulSet manifest YAML file will look like this: ```yaml volumeMounts: - name: my-volume mountPath: /data/path volumeClaimTemplates: - metadata: name: my-volume spec: accessModes: [ "ReadWriteOnce" ] storageClassName: "my-stg-class" ## Dynamic storage provisioning resources: requests: storage: 1Gi ## Storage request ``` You’ll see more about this when we get to **“How to create a StatefulSet session”** later in this blog post. ## What Is the Role of a Service in StatefulSets? A Service is needed in a StatefulSet for communication across Pods. It links all of the Pods in the StatefulSet and also controls its network domain. The question is, what type of service is suitable for a StatefulSet? A StatefulSet needs a headlessService for Pods discovery and to maintain the Pods’ sticky network identity, which is one of the characteristics of StatefulSets. Moreover, you need another Service type to expose the application to the outside world or get an external IP. You can read more on [Services](/blog/exposing-apps-with-services/) in an earlier part of this series. The Headless Service is referenced in the StatefulSet manifest YAML file by declaring a **“serviceName”** field as a child of a **“spec”** property. The value of this field must be the same as the Headless Service name. ## How to Create a StatefulSet A StatefulSet is created by declaring a manifest YAML file just like Deployment, but with a different **“kind”** value; in this case, StatefulSet. There are also various components highlighted above that are needed to create a StatefulSet. These are Headless Service, persistentVolume (PV) and persistentVolumeClaim (PVC). PV & PVC are required if you are using static storage provisioning in a local cluster. If, however, you are using cloud provider storage from AWS, Azure or GCP, which allows for dynamic storage provisioning, creating a storageClass object would be a suitable option. You can read more on [static (PV & PVC)](/blog/keeping-the-state-of-apps-4-persistentvolumes-and-persistentvolum/) and [dynamic (storageClass)](/blog/keeping-the-state-of-apps-5-introduction-to-storage-classes/) storage provisioning methods in a previous part of this series. Before we begin, it is advised to have a basic knowledge of Kubernetes objects like [Pod](/blog/introduction-to-pods/), [Deployment](/blog/introduction-to-kubernetes-deployment/), [Service](/blog/exposing-apps-with-services/), [volumes & volumeMount](/blog/keeping-the-state-of-apps-1-introduction-to-volume-and-volumemounts/), [PV, PVC](/blog/keeping-the-state-of-apps-4-persistentvolumes-and-persistentvolum/) and [storageClass](/blog/keeping-the-state-of-apps-5-introduction-to-storage-classes/), to follow this exercise. We will go through a hands-on practice on a running Kubernetes cluster, so it’s imperative to have one with the `kubectl` command-line tool already configured to talk to the cluster. [KubeOne](https://docs.kubermatic.com/kubeone/v1.2/getting_kubeone/) allows you to create a Kubernetes cluster in any environment easily. Check out our [documentation](https://docs.kubermatic.com/kubeone/v1.2/getting_kubeone/) on this to get started. Alternatively, you can just use the Kubernetes playground to practice. The following steps will guide you on how to create a StatefulSet and other necessary components.  First, create the headless service by setting the clusterIP field to **“None”**. The configuration will look like this: **Step 1:** ```bash $ vim headless-service.yaml ``` Copy the below configuration into the above file. ```yaml apiVersion: v1 kind: Service metadata: name: my-service labels: app: service-label spec: ports: - port: 80 name: web clusterIP: None ## Headless service selector: app: service-label ``` **Step 2:** Create the headless service using the `kubectl create` command. ```bash $ kubectl create -f headless-service.yaml service/my-service created ``` **Step 3:** Use `kubectl get` command to check the details of the service. ```bash $ kubectl get service my-service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-service ClusterIP None <none> 80/TCP 37s ``` **Step 4:** Create a storageClass with the below YAML manifest file. storageClass is used in this case because a host cloud provider was used for the cluster. If you are using a local cluster, you will need to create PV and PVC. Check our previous post on how to provision storage using PV and claim it using PVC. ```bash $ vim s-class.yaml ``` ```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: my-stg-class ## Name of the SC that will be referenced in the StatefulSet manifest file provisioner: kubernetes.io/aws-ebs ## Provisioner for AWSElasticBlockStore plugin volumeBindingMode: WaitForFirstConsumer # The binding will wait until the StatefulSet is created ``` Use `kubectl create` command to create the storageClass. ```bash $ kubectl create -f s-class.yaml storageclass.storage.k8s.io/my-storageclass created ``` **Step 5:** Check the details of the storageClass using `kubectl get` command: ```bash $ kubectl get storageclass my-storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE my-storageclass kubernetes.io/aws-ebs Delete WaitForFirstConsumer false 3m37s ``` **Step 6:** Now copy and paste the below configuration in a YAML file with your choice’s name to create a StatefulSet object. ```bash $ vim stateful-set.yaml ``` ```yaml apiVersion: apps/v1 kind: StatefulSet metadata: name: my-stateful-set spec: selector: matchLabels: app: service-label # has to match .spec.template.metadata.labels serviceName: "my-service" # has to match the created service name. replicas: 3 # Number of Pod replicas to be created. It is 1 by default template: metadata: labels: app: service-label # has to match .spec.selector.matchLabels spec: terminationGracePeriodSeconds: 10 containers: - name: nginx image: nginx ports: - containerPort: 80 name: web volumeMounts: - name: my-volume mountPath: /data/path volumeClaimTemplates: - metadata: name: my-volume spec: accessModes: [ "ReadWriteOnce" ] storageClassName: "my-storageclass" #must match the created StorageClass name resources: requests: storage: 500Mi # storage request ``` Create the StatefulSet using the `kubectl create` command: ```bash $ kubectl create -f stateful-set.yaml statefulset.apps/my-stateful-set created ``` You can view the processes of how the Pods are being created using `kubectl get pods -l app=service-label -w` command where **app=service-label** is the same as the label used in the manifest file. You also need to install [tmux](https://github.com/tmux/tmux/wiki/Installing) to divide your terminal into two, which will allow you to run the commands in the first terminal and watch the processes in the second. You must first run the above command on the first terminal to watch the processes before running the command to create the StatefulSet on the second. If everything works well, the viewed terminal output should look like this: ```bash NAME READY STATUS RESTARTS AGE my-stateful-set-0 0/1 Pending 0 0s my-stateful-set-0 0/1 Pending 0 6s my-stateful-set-0 0/1 ContainerCreating 0 6s my-stateful-set-0 0/1 ContainerCreating 0 24s my-stateful-set-0 1/1 Running 0 36s my-stateful-set-1 0/1 Pending 0 0s my-stateful-set-1 0/1 Pending 0 6s my-stateful-set-1 0/1 ContainerCreating 0 6s my-stateful-set-1 0/1 ContainerCreating 0 12s my-stateful-set-1 1/1 Running 0 15s my-stateful-set-2 0/1 Pending 0 0s my-stateful-set-2 0/1 Pending 0 6s my-stateful-set-2 0/1 ContainerCreating 0 6s my-stateful-set-2 0/1 ContainerCreating 0 23s my-stateful-set-2 1/1 Running 0 26s ``` The above output shows the order in which the Pods are created. Use `kubectl get` command to check the Pod status to see if they are ready. **Step 7:** Check the details of the StatefulSet, Pods, PV and PVCs using `kubectl get` command: Check the details of the StatefulSet: ```bash $ kubectl get statefulset my-stateful-set NAME READY AGE my-stateful-set 3/3 5m25s ``` The output shows that the 3 Pod replicas have been created and ready. Check the status of the Pods: ```bash $ kubectl get pods NAME READY STATUS RESTARTS AGE my-stateful-set-0 1/1 Running 0 7m6s my-stateful-set-1 1/1 Running 0 6m44s my-stateful-set-2 1/1 Running 0 6m26s ``` Check the status of the PersistentVolume: ```bash $ kubectl get pv NAME CAPACITY ACCESS MODES STATUS CLAIM STORAGECLASS AGE pvc-1dcfd012 1Gi RWO Bound default/my-volume-my-stateful-set-1 my-stg-class 5m8s pvc-2ceee9d3 1Gi RWO Bound default/my-volume-my-stateful-set-2 my-stg-class 4m49s pvc-8cfe94f5 1Gi RWO Bound default/my-volume-my-stateful-set-0 my-stg-class 5m30s ``` Check the status of the PersistentVolumeClaim: ```bash $ kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE my-volume-my-stateful-set-0 Bound pvc-8cfe94f5 1Gi RWO my-stg-class 34m my-volume-my-stateful-set-1 Bound pvc-1dcfd012 1Gi RWO my-stg-class 33m my-volume-my-stateful-set-2 Bound pvc-2ceee9d3 1Gi RWO my-stg-class 33m ``` In the above output, the Pod names have specific numbers attached to them from 0 - 2, unlike Deployment where random numbers and letters are attached to a Pod name.  Moreover, the Pods are created sequentially. The Pod **“my-stateful-set-0”** is created first, followed by **“my-stateful-set-1”** and then **“my-stateful-set-2”**. If you don’t want them labelled sequentially, you can include a **“podManagementPolicy”** property in the StatefulSet YAML file with its value set to **“parallel”**.  ## **StatefulSet Use Case** We will test the use case of StatefulSet using the following steps: getting into one of the Pods, creating a file and deleting the Pod. The Pod will be recreated using replicas. We will then check if it has the same name as the one that was deleted and if the data created earlier still exists in the Pod. **Step 1:** Exec into one of the pods using the `kubectl exec` command. Pod **“my-stateful-set-1”** will be used in this case. ```bash $ kubectl exec -it my-stateful-set-1 -- bin/bash root@my-stateful-set-1:/# ``` **Step 2:** Change to the directory where the volume is mounted, create and save a file into the directory: ```bash root@my-stateful-set-1:/# cd data/path root@my-stateful-set-1:/data/path# echo This is a StatefulSet Message > stset.txt root@my-stateful-set-1:/data/path# cat stset.txt This is a StatefulSet Message pod "my-stateful-set-1" deleted ``` **Step 3:** Exit from the Pod, delete the Pod and let it recreate: ```bash $ kubectl delete pod my-stateful-set-1 pod "my-stateful-set-1" deleted ``` Check the Pod status to see if they are up again: ```bash $ kubectl get pods NAME READY STATUS RESTARTS AGE my-stateful-set-0 1/1 Running 0 33m my-stateful-set-1 1/1 Running 0 6s my-stateful-set-2 1/1 Running 0 33m ``` The output shows that the Pod is up again with the same name. One way to know this is to check the difference in the “AGE” column of all the Pods. **Step 4:** Exec into the Pod once again and check the data created earlier before the Pod was deleted: ```bash $ kubectl exec -it my-stateful-set-1 -- bin/bash root@my-stateful-set-1:/# cd data/path root@my-stateful-set-1:/data/path# ls stset.txt root@my-stateful-set-1:/data/path# cat stset.txt This is a StatefulSet Message root@my-stateful-set-1:/data/path# exit ``` ## Scaling StatefulSet up or Down You can scale StatefulSet up or down by running the below command on the terminal. The value depends on how many Pod replicas you need. **To scale down:** We will scale down the previous Statefulset from 3 to 1 replica using `kubectl scale` command and also watch the process to see the scaling order. ```bash $ kubectl scale statefulset my-stateful-set --replicas=1 ``` Check the StatefulSet and Pod status with `kubectl get` command: ```bash $ kubectl get statefulset NAME READY AGE my-stateful-set 1/1 6m ``` ```bash $ kubectl get pod NAME READY STATUS RESTARTS AGE my-stateful-set-0 1/1 Running 0 15m ``` **To Scale-up:** The StatefulSet will be scaled-up from 1 to 6 replicas. ```bash $ kubectl scale statefulset my-stateful-set --replicas=6 ``` Check the StatefulSet status: ```bash $ kubectl get statefulset NAME READY AGE my-stateful-set 6/6 102m ``` Use `kubectl get` command to check the status of the Pods: ```bash $ kubectl get pods NAME READY STATUS RESTARTS AGE my-stateful-set-0 1/1 Running 0 59m my-stateful-set-1 1/1 Running 0 59m my-stateful-set-2 1/1 Running 0 59m my-stateful-set-3 1/1 Running 0 2m47s my-stateful-set-4 1/1 Running 0 2m32s my-stateful-set-5 1/1 Running 0 2m5s ``` The above output shows that the pods start terminating from **my-stateful-set-5** to **my-stateful-set-1** to scale the replica down to 1. ### Clean up: Delete the StatefulSet, Service, StorageClass and PersistentVolumeClaims using `kubectl delete` commands in that order. You can view the process while deleting the StatefulSet to see the order in which the Pods terminate. ```bash $ kubectl delete statefulset my-statefulset NAME READY STATUS RESTARTS AGE my-stateful-set-0 1/1 Running 0 4h59m my-stateful-set-1 1/1 Running 0 23m my-stateful-set-2 1/1 Running 0 23m my-stateful-set-3 1/1 Running 0 23m my-stateful-set-4 1/1 Running 0 15m my-stateful-set-5 1/1 Running 0 15m my-stateful-set-5 1/1 Terminating 0 16m my-stateful-set-2 1/1 Terminating 0 25m my-stateful-set-0 1/1 Terminating 0 5h1m my-stateful-set-3 1/1 Terminating 0 24m my-stateful-set-1 1/1 Terminating 0 25m my-stateful-set-4 1/1 Terminating 0 17m my-stateful-set-2 0/1 Terminating 0 25m my-stateful-set-1 0/1 Terminating 0 25m my-stateful-set-5 0/1 Terminating 0 16m my-stateful-set-3 0/1 Terminating 0 25m my-stateful-set-0 0/1 Terminating 0 5h1m my-stateful-set-4 0/1 Terminating 0 17m my-stateful-set-4 0/1 Terminating 0 17m my-stateful-set-5 0/1 Terminating 0 16m my-stateful-set-5 0/1 Terminating 0 16m my-stateful-set-3 0/1 Terminating 0 25m my-stateful-set-3 0/1 Terminating 0 25m ``` The output shows that the Pods are terminated concurrently without waiting for any others to complete the process. Check the Pods status to see if they have been deleted: ```bash $ kubectl get pods No resources found in default namespace. ``` ### Summary: There are some limitations with StatefulSets when compared to Deployment. There is the possibility that the Pods remain unterminated. So, you can scale down the StatefulSet replicas to 0 first and then delete the StatefulSet. Also, the StatefulSet’s volumes remain intact for data preservation until its PersistentVolumeClaims are deleted. The PersistentVolumeClaims, as well as other components, must be deleted manually. ## Learn More * Read more on [StatefulSets](https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/) * Learn more about [how to deploy a StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) --- ## Kubernetes Storage Classes: An Introduction - **URL:** https://www.kubermatic.com/blog/keeping-the-state-of-apps-5-introduction-to-storage-classes/ - **Date:** 2026-04-30 - **Description:** Learn about Storage Classes, including creating and referencing StorageClass with PersistentVolumeClaim and optimizing data persistence. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Seyi Ewegbemi ## **Introduction to Storage Classes** The [previous installment in this series](/blog/keeping-the-state-of-apps-4-persistentvolumes-and-persistentvolum/) outlined two volume provisioning methods, static and dynamic. The exercise on creating a PersistentVolume was based on static volume provisioning, while this segment will focus on the dynamic method using StorageClass. You’ll learn how to make a volume request of any size, without worrying about whether or not it’s available in the storage pool. Here’s what we’ll cover: * What is a StorageClass? * How to create a StorageClass * How to reference a StorageClass in a PersistentVolumeClaim (PVC) * How do StorageClasses help to make data persistence more dynamic? ## **What Is a Kubernetes StorageClass?** A StorageClass is a Kubernetes resource that enables dynamic storage provisioning. The administrator configures the StorageClass, which can then no longer be modified. First the StorageClass is created, then the PersistentVolumeClaim and finally the Pod. When a PVC is created, Kubernetes creates a PersistentVolume and binds it to the PVC automatically, depending on the VolumeBindingMode used in the StorageClass configuration. These three Kubernetes objects are required to check the test case of a StorageClass. ## **How to Create and Reference a StorageClass in a PVC** Creating a StorageClass is similar to the way we created previous Kubernetes objects, except that it has its own properties and values, which will be described later. The configuration file below is an example of a StorageClass manifest file: ```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: my-storageclass provisioner: kubernetes.io/aws-ebs volumeBidingMode: WaitForFirstConsumer ``` The **apiVersion**, **kind**, and **metadata** are common properties that you will be familiar with from our previous exercises on Kubernetes objects. The new, additional properties are: * **Provisioner:** This property is essential, and it must be specified. It is a field that determines which volume plugin should be used to provision the PVs. There are many volume plugins that are classified as either internal or external provisioners. (e.g., GCEPersistentDisk, Azuredisk, Azurefile, AWSElasticBlockStore, NFS, Flexvolume, Local, etc.). The first four use internal provisioner plugins, while the last three are external. Each of these has its config example used as part of the provisioner field’s value, depending on which volume plugin you want to use. The table below shows the standard volume plugins and their provisioners. ![plugins and their provisioners](/static/storage-class.jpg) You can find more volume plugins and their provisioners in the [Kubernetes official documentation](https://kubernetes.io/docs/concepts/storage/storage-classes/). * **volumeBindingMode:** This property has two values, Immediate and WaitForFirstConsumer. * **Immediate Mode:** This mode involves the automatic volume binding of PVs to PVCs with a StorageClass once a PVC is created. * **WaitForFirstConsumer Mode:** This mode will delay the binding and dynamic provisioning of PVs, until a Pod that will use it is created. The following stages will guide you through how to create and use a StorageClass. **Stages:** 1. Create a StorageClass 2. Create a PVC for storage request from StorageClass 3. Create a Pod to consume the claim by referencing the PVC in the Pod ## **Hands-on Practice** Basic knowledge of [Pod](/blog/introduction-to-pods/), [Deployment](/blog/introduction-to-kubernetes-deployment/), [Volume](/blog/keeping-the-state-of-apps-1-introduction-to-volume-and-volumemounts/), [PersistentVolume and PersistentVolumeClaim](/blog/keeping-the-state-of-apps-4-persistentvolumes-and-persistentvolum/) is recommended to make the most of this hands-on practice. Please refer to our previous posts on these concepts if you need to familiarize yourself with them. In addition, a running Kubernetes cluster is required for this exercise. You can simply create a single Node cluster using [Kubeone](https://docs.kubermatic.com/kubeone/v1.2/getting_kubeone/). The documentation and guide can be found [here](https://docs.kubermatic.com/kubeone/v1.2/getting_kubeone/). **Stage 1:** **Create a StorageClass:** Here are the steps to create a StorageClass: **Step 1:** Create a file with vim or any editor of your choice: ```bash $ vim st-class.yaml ``` **Step 2:** Copy and paste the above StorageClass manifest file into the created YAML file and create the StorageClass with `kubectl create` command. ```bash $ kubectl create -f st-class.yaml storageclass.storage.k8s.io/my-storageclass created ``` **Step 3:** Check the details of the StorageClass: ```bash $ kubectl get sc my-storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE AGE my-storageclass kubernetes.io/aws-ebs Delete WaitForFirstConsumer 9s ``` **Stage 2:** **Create a PVC:** You can read more on [PVC](/blog/keeping-the-state-of-apps-4-persistentvolumes-and-persistentvolum/) in this [previous](/blog/keeping-the-state-of-apps-4-persistentvolumes-and-persistentvolum/) chapter in the series. A **“storageClassName”** property should be added to the PVC manifest file, with the StorageClass name created in stage 1 as its value, which in this case will be **“my-storageclass”**. When this field is omitted, the default StorageClass, which is **“Standard,”**, will be provisioned with the PVC. It is always suggested to reference the StorageClass name in the PVC to use the desired StorageClass. The complete configuration will look like this: ```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-claim spec: accessModes: - ReadWriteOnce storageClassName: my-storageclass resources: requests: storage: 2Gi ``` **Step 1:** Create the PVC with `kubectl create` command: ```bash $ kubectl create -f my-pvc.yaml persistentvolumeclaim/my-claim created ``` **Step 2:** Check the status of the PVC: ```bash $ kubectl get pvc my-claim NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE my-claim Pending my-storageclass 9s ``` The status output shows that the PVC is pending, because **WaitForFirstConsumer** is used as the **VolumeBindingMode** value in the StorageClass configuration. It will remain in this state until a Pod that will consume the claim is created. Now, Check the **PersistentVolume** status using `kubectl get` command: ```bash $ kubectl get pv No resources found ``` You can’t see an available PersistentVolume on the cluster, even though a PVC has been created. Delete the PVC and then the StorageClass, change the **volumeBindingMode** value in the StorageClass manifest file to **“Immediate,”** create the two objects again and check the status. You can now go to **stage 3** and create a Pod. **Stage 3:** **Create a Pod to consume the claim:** The previous configuration will be used. The **PVC** name must be the same as the **persistentClaimVolume.claimName** field’s value in the Pod. The configuration will look like this: ```bash $ vim st-pod.yaml ``` ```yaml apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: stclass-test image: nginx volumeMounts: - mountPath: "/app/data" name: my-volume volumes: - name: my-volume persistentVolumeClaim: claimName: my-claim ``` **Step 1:** Create the Pod with `kubectl create` command: ```bash $ kubectl create -f st-pod.yaml pod/my-pod created ``` **Step 2:** Check the Pod status: ```bash $ kubectl get pods my-pod NAME READY STATUS RESTARTS AGE my-pod 1/1 Running 0 3m ``` Check the status of the PVC again: ```bash $ kubectl get pvc my-claim NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE my-claim Bound pvc-6e5dae64 2Gi RWO my-storageclass 10m ``` As shown above, the status of the PVC has changed from a pending to a bound state. This simply means that all three objects created are now bound or reference one another. The next step is to check the PersistentVolume status again using the `kubectl get` command: ```bash $ kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS AGE pvc-6e5dae64 2Gi RWO Delete Bound default/my-claim my-storageclass 99s ``` If everything works correctly, you should see the same output as above. You can now see that a PersistentVolume was automatically created when we created the Pod. This is dynamic volume provisioning using StorageClass. The persistent functionality can be tested using ssh in the Pod; create and save a file inside the Pod, then delete the Pod. Re-create the Pod again and check for the file that was created before deleting the Pod. You can do this by following these steps: **Step 1:** Exec into the Pod: ```bash $ kubectl exec -it my-pod -- bin/bash root@my-pod:/# ``` **Step 2:** Change to the mount directory—The same directory for volumeMount in the Pod manifest file. ```bash root@my-pod:/# cd app/data root@my-pod:/app/data# ``` **Step 3:** Create and store some data in a text file and check the file to be sure the data is written in the file, and exit the Pod: ```bash root@my-pod:/app/data# echo My StorageClass Message > stclass.txt root@my-pod:/app/data# cat stclass.text My StorageClass Message ``` **Step 4:** Now delete the Pod: ```bash $ kubectl delete pod my-pod pod "my-pod" deleted ``` ```bash $ kubectl get pods No resources found ``` Recreate it: ```bash $ kubectl create -f st-pod.yaml pod/my-pod created ``` Check the Pod status to confirm if it is running: ```bash $ kubectl get pods NAME READY STATUS RESTARTS AGE my-pod 1/1 Running 0 89s ``` **Step 5:** Exec into the Pod again and check that the file was created before the Pod was deleted: ```bash $ kubectl exec -it my-pod -- bin/bash root@my-pod:/# cd /app/data root@my-pod:/app/data# ls stclass.text root@my-pod:/app/data# cat stclass.text My StorageClass Message ``` The data that was created remained beyond the Pod’s lifecycle **Clean-Up:** To clean up your Kubernetes environment after this exercise, you can delete the Pod, PVC, and StorageClass using the `kubectl delete` command. This ensures that no residual resources are left running in your cluster, especially if you're managing limited resources. By using the command `kubectl delete storageclass`, you can remove the StorageClass resource from your Kubernetes cluster when it's no longer needed, making sure you're not using up resources you don't need. **Summary:** StorageClass is a Kubernetes object that preserves your application data by storing it in the cloud. It is based on which volume plugin is used to provision the StorageClass. (e.g., in the above case, the AWS cloud). Manual provisioning of PersistentVolume in advance is not required, as it is in the static provisioning method. Instead, the StorageClass object must be created before the PersistentVolumeClaim. [Next in our series](/blog/keeping-the-state-of-apps-6-introduction-to-statefulsets/), we’ll look at the best practice for taking care of stateful applications by introducing another Kubernetes object, a StatefulSet. Applications in Kubernetes can be either stateful or stateless. We have worked on various stateless applications in previous parts of this series, so the next will focus on creating applications using a StatefulSet. We’d love to hear from you! Please do not hesitate to [contact us](mailto:marketing@kubermatic.com) with any thoughts or questions, or any clarifications you might want about Kubernetes Storage Classes. ## **Learn More** * Learn more about [Storage Classes](https://kubernetes.io/docs/concepts/storage/storage-classes/) * Check our more [StorageClass resources](https://kubernetes.io/blog/2017/03/dynamic-provisioning-and-storage-classes-kubernetes/) * Read more on [Setting the default StorageClass](https://cloud.google.com/anthos/gke/docs/on-prem/1.3/how-to/default-storage-class) --- ## Kubermatic & DifiNative: Top-notch Services Delivery - **URL:** https://www.kubermatic.com/blog/kubermatic-partners-with-difinative-to-deliver-best-in-class-services/ - **Date:** 2026-05-07 - **Description:** The cooperation of DifiNative and Kubermatic provides new and existing customers with best-in-class services for the Kubermatic product suite. - **Categories:** Company - **Tags:** Announcements - **Authors:** Kristin Wittig We are delighted to announce our strategic partnership with DifiNative, a specialized cloud native engineering company with global infrastructure services experience. As Kubernetes installations grow in size and complexity, this partnership provides new and existing customers with best-in-class services for our Kubernetes automation product portfolio.  “We are incredibly excited to be the Services partner for Kubermatic. We see a strong synergy in the values and offerings of both companies. Our purpose is to exclusively operate in cloud native services and bring deep platform engineering expertise to take modern digital applications to an industrialised market facing product or service,” says Saji Thoppil, Founder and CTO at DifiNative.  At Kubermatic, we envision the cloud native applications of tomorrow will be based on focused and converging operations, achieved with minimum resources and maximum automation. We are therefore delighted to have found a partner that shares and aligns with this mindset, to enhance the value that we will be able to deliver to our customers. By combining DifiNative’s deep cloud native knowledge and technology practice with our enterprise-proven software solutions, IT teams can deploy and manage their mission-critical cloud native services with ease and confidence. The benefits of this partnership for customers include:   * Simple and safe migration to scalable Kubernetes infrastructure without the need to invest in and build a dedicated operations team  * Rapid rollout and secure 24X7 operations by highly skilled SRE teams * Best developer experience, ubiquitous over any infrastructure   ## About DifiNative  [DifiNative](http://www.difinative.com) specializes in a range of technologies that are crucial to bringing a cloud native project to a full production deployment. They operate exclusively in the cloud native solution engineering area that helps customers take their modern digital application to a commercial, market facing product or service. The company is headquartered in Bangalore, India and founded by industry veterans who have decades of experience in designing, building and scaling cloud and infrastructure services globally.  To learn more about our partnership, click [here](https://www.kubermatic.com/contact-us/) to contact us. --- ## Kubermatic News for June 2021 - **URL:** https://www.kubermatic.com/blog/kubermatic-news-for-june/ - **Date:** 2026-05-07 - **Description:** Join our AMA session with CEO Sebastian to learn more about container adoption and sign up for ContainerDays Hybrid 2021. - **Categories:** Company - **Tags:** Announcements - **Authors:** Sebastian Scheele Curious to see how the container management market will develop over the next few years? Gartner’s Market Guide for Container Management is forecasting some very remarkable results: **The market** is expected to **grow at an annual rate of 34%, exceeding $1 billion in revenue by 2025.** Proper management of containers is essential when enterprises rely on them to quickly deploy and update applications. From an operational perspective, containers are a key component of the **present-day application platform infrastructure** for enterprises. According to Gartner’s survey, the top 2 reasons that make container adoption so popular are **Agility (which allows developers to integrate applications with their existing DevOps environment)** and a higher level of **support of modern application architectures.** Container adoption including automated deployment of containerized applications to operating systems and the public cloud does, however, come with some challenges: Lack of skilled resources, operational complexity and security concerns ranked as the top three in the same survey. That’s why the right **container management tool** is so crucial: its usefulness is based on its ability to help IT teams **easily operate and manage clusters and resources,** and **deploy containerized workloads at scale.** At Kubermatic, we chose Kubernetes as our container orchestration platform to deliver innovative solutions for automated cloud native operations and to run containerized workloads at scale across different types of environments. The combination of these powerful forces has made Kubermatic the leading specialist for Kubernetes in Europe today. Are you thinking about simplifying the management of your clusters but not sure on how to get started? Join us for our **Ask Me Anything About Container Adoption** session on Tuesday, August 17 at 5pm (CEST) and I’ll be happy to share our knowledge and experience with you and help you to succeed in this endeavour. *P.S.: We just launched a promotion on Capterra! The first 100 reviewers of our Kubermatic Kubernetes Platform get a $20 Voucher! Click [here](https://review.capterra.com/Feedback-Kubermatic-Kubernetes-Platform-199419-3186045353).* ## PRODUCT UPDATES ![Laptop on the table ](/static/june-kubermatic-news-products.jpeg) ## **Edge Computing, Datacenter & Compliance, and Other Platform Enhancements With KKP** The opportunities for container and cloud native technologies as they apply to edge computing use cases are exciting. Container technology is being deployed in edge configurations to push compute and storage resources to the end user. But with hard- and software spread across thousands of locations, managing these distributed systems requires the right tools. Little wonder that advanced edge computing capabilities have a high priority on our Product Roadmap for Kubermatic Kubernetes Platform (KKP). Check out our roadmap for more details and important highlights. **[Find Out More](https://f.hubspotusercontent40.net/hubfs/4550048/Marketing/KKP%20Roadmap%20Highlights%202021.pdf?utm_medium=email&_hsmi=2&_hsenc=p2ANqtz--YJa3rA6RNYjyv_X9hkbeKUy9i_z_ZkXPDc-X4IFWFIYxXhEzOTQtRuJRlMAKP5nsZMM6BWsHtpc6dNfv_MbUQxX4sSA&utm_content=2&utm_source=hs_email)** ## **Leave Us Your Review on Capterra and Get Your $20 Gift Card** Have you already experimented with Kubermatic Kubernetes Platform to automate your Kubernetes clusters anywhere? Great! What would be even better is if you would post a review about your experience with KKP on Capterra. The first 100 reviewers get a $20 gift card - so, better hurry;) **[Get Your $20 Gift Card](https://review.capterra.com/Feedback-Kubermatic-Kubernetes-Platform-199419-3186045353?utm_medium=email&_hsmi=2&_hsenc=p2ANqtz--shK0fUMnmYHe8OloqjY80lwvz4sRaIwp87BtTisZMLhBf4poL3Y9LnemSpb2wRiOyKhnu5RNk4QwSHr9bhg-PdMAkbA&utm_content=2&utm_source=hs_email)** ## **Kubermatic Blog** ![Typing on the keyboard](/static/june-kubermatic-news-kubermatic-blog.jpeg) * [Kubernetes as a Container Orchestration Tool](https://it.t.hubspotemail.net/e2t/tc/VWsyfy7tR0PBW4yM49b4W38fkW3V7XmG4tnR5KMyCDmr3lGn5V1-WJV7CgZWGW17kkVg452-VtW1P32Tq2QFvCJW1lWBYw5JFYjkW2vlN8w7zW857W7Nzz8B1VjB9zW3yCqpb4H0pZJW3Dj5kK45Rn68W37P1s524Z8zGN2ZRtCyRzyVnW2rTJJv4dbwG1W3mHhts1Bbpb1W3ZXTDY4ytn_dV-D-rY5-yrjfVYns4y8j4gK7W8HkJrH3scHy-W86-hBX8PLdLyW75lzm-3CtrkLN1WWqqCvsdsXW6Tlm_658MYd_W6PSCYJ5cmnb3W33_zvm3hDJtvW8b5r4N3yLn4nW8lrnYm8zh9l1W70-WWc51_Xkh31lR1) * [The Complete Guide to Kubernetes Metrics](https://it.t.hubspotemail.net/e2t/tc/VWsyfy7tR0PBW4yM49b4W38fkW3V7XmG4tnR5KMyCDmr3lGn5V1-WJV7CgYpkW193z4V3ysq2nW32QbfK1nx10LN60Bqrg-jnkYN85fjQrw055BW8hK5hZ7tk_ZhMxgc2fGfdd2VwzT0B3LHyn8W36_g_H6nq3sJN6jlhY-8zdcvVNQX1L3Rt_2XW1MBz8y1VbX4nW6HV86L92cpfVW3RQwS99cQn-gN8Yct7TqyPr1W4Gy1Xm2Fz_knW1Tnkpx5qxpqZN4yb0McGTm1TN5XFB2Z9SF10N47l-G3_BDX6W5cYDf05hSRM-W1YRN7C7xfyljN82pNl56L3PYW149yrx6qL938N1Gh8jVTDxKV3dFt1) * [How to Implement Kubernetes Monitoring, Logging, and Alerting at Scale](https://it.t.hubspotemail.net/e2t/tc/VWsyfy7tR0PBW4yM49b4W38fkW3V7XmG4tnR5KMyCDn13lGnJV1-WJV7CgSSMW4PCbvX76kN6WW4czz-P5y4HT0W21Ls735lq92QW1FwzyS6vL5sTW8CWssH89R5khW4V7GCy46n5ZsN6PfTTK3l_dzW7kZ0rt7Ph3j7Vq7Vgt54LVc8N5vYJtFW_xfYW5JMmPv8Y4S2ZW7SGxwk4pKMPwW2-zxv18w8nPgM6L--650NrxW7khv2V16RpJxW6NL0R12zxqZDW1Jg1SQ8rfJf-W6bCMNS4v6v_kN7dgMPqrt1gMVXtJV48W-Sx0W7ZGdtc2vpb6xW9j93gZ53GfmxW7XHYQV61HcCGW8KKd9c2582wTMx65B1y562ZW6f4K2R55W6rhW94J51t1p1BtbW1vCdsg80hHCN32Sf1) **[Discover Our Blog](https://www.kubermatic.com/blog/?utm_medium=email&_hsmi=2&_hsenc=p2ANqtz-_4HKBi7Mscdn7Qvv2izessiPSZGVY1r6wNI8pmNM1Do1AtQvIrEy6_3JSTprQg4zk8dA__NRmIuGaCC3nk49JsHulTbw&utm_content=2&utm_source=hs_email)** ## KUBERMATIC RESOURCES ![A library with many books on shelves](/static/news-june-resource.jpeg) **\#1 Demo** KKP enables Operations and DevOps teams to centrally manage VMs and containerized workloads across hybrid-cloud, multi-cloud, and edge environments with an intuitive self-service developer and operations portal. [Automate Your Clusters Across Multi-Cloud with KKP](https://it.t.hubspotemail.net/e2t/tc/VVzQSB29c75QMb_QjDwVWlVV5XFwB4tbF2bN8kT_C93lGnpV1-WJV7CgT_gW7Vmrdx5kP5z3W8dPrdl1g4sVbW5wv19W4SS8YJW69M2907LjKJbW2B_D3D6vwyh_W62h8k38l2tXyVnfz_X61Yx4HW33dt495knZX3W2v4VGf71zwk5W1GHj-N4csf92W2rqlfF3XH7V1W5MprpR8NmSk2W1D3QRg2m9zkgV5xScP7zF79wW8kXlq-6BMFhzW7Lp0C-3rgnfNW99cTxB5py5MHW2SgcsB6RNmGKN3Y-x9r5pQZWW8FW6h341Y2d-W4pny7h1Z_7W5W2Mw5Jp1jBKc7W57mpJ832DwfkW4FGWH-1wltF9W5SGv4w6v6k9qW2LdH8d2HP2kD34lp1) **\#2 Checklist** Kubernetes is very powerful, but the path to its adoption isn’t always easy. To help you determine quickly and easily if you are ready to run Kubernetes in production, we’ve created a very handy and comprehensive checklist.  [The Ultimate Checklist for Running Kubernetes in Production](https://it.t.hubspotemail.net/e2t/tc/VVzQSB29c75QMb_QjDwVWlVV5XFwB4tbF2bN8kT_C93lGnpV1-WJV7CgJcCW7x4Vz57dkNQPW1_ZN-549wg7_Vz6kCq5C6fpLW8fKQN38SGgSYVNNbcR4-YLrKW4KbNCv2-w74SW6Tc26L2sd0SWW1LpRxn3yCQxpW8ZFJ5h8B8thZW1NTb3t6qG7SrW6SCDtX6ngfDZW8Q_TQm2XCGV3W4gfMTZ64zbVcW3r1V4L6SVfxmW3YfkvD51RfwDVztfxG6Hcpn3W1DD0C86lyzyvW2nxzVw55LhR-W2xfYtR2rVjm-W53Hhxf5TXrNMW8MgmsV274xFQW6X5jbW5SxWcdMwT2Ggmd3sLW4X_JfX16kK7tW8JTR-_49PD8LW839tB05RJCTK33BR1)  **\#3 Webinar Series** In our Kubernetes 101 series, we cover the theoretical and technical fundamentals of Kubernetes and cloud native technologies and help you get started with containers and Kubernetes. [Kubernetes 101 Webinar Series](https://it.t.hubspotemail.net/e2t/tc/VVzQSB29c75QMb_QjDwVWlVV5XFwB4tbF2bN8kT_BV3lGn5V1-WJV7CgDBHW8XQrNF3s8bX5W4bxks953sXfnW7jkk212MzNsYW48Vbn25bvbwsW3qKdJ96yCjb3W2_RG7V6Qn06yW6H4Yg-3j64KkW4D6_My6SpZSbW8Hk7JN2xcm6rW8TQhFy2mF9NXW2s34b61Bh9pQVCfZwv42MLSSW53HyJJ1_Ny2RW4NvJg6960ZcnW1h02GF3lWWwFW5DG8xS7Y_dRyW3JsN4R8lKB_8W5TvctK7pWDvMW72KbKY2R1nzLW60-r-n37-LJZW6XS4p16_TbpMVXW0Hj5dBlZPVsnjSd6cpfXNW3dwY6Q8SzT-Q3nqW1) **[Browse Our Resource Library](https://www.kubermatic.com/resources/?utm_medium=email&_hsmi=2&_hsenc=p2ANqtz-9nvJbFALelj4nF9pvweFWhG_0x8N0UB_LsImW_h-hi5Q5yvTJtQbSS3WvPYWWd2rf8_4PoyMyL4VhOglVI6SfV5DpKhA&utm_content=2&utm_source=hs_email)** ## **Upcoming Events** ![Ship port with cranes](/static/kubecarrier-webinar_join-us-at-containerdays-2021.png) ## **ContainerDays Hybrid 2021** Whether you're just starting your container adoption journey or already have your initial projects up and running, [ContainerDays](https://it.t.hubspotemail.net/e2t/tc/VVzQSB29c75QMb_QjDwVWlVV5XFwB4tbF2bN8kT_BV7hMntV5X_Kf7CgXH1W6QfgwK783RqFW6rnxr32r4MvbW8qkgmJ1SjVJrW6JTHF62VHTjqW6Jz32b2l-HNlM6dprZHdQcBW2mz1Xq3TmZTrW62xwb87mTS9wW8X6HDw57SzpmW83LJF77dLfZ6W6z9bY82MjxzvW50Jyyq47V2hFVpFmVW5sf1hVW55RLby8BlqxLW8qNMb15JQl0xW6_vPLQ3TYjHnW4wdRt94j0DcxW8dF4-T4XtlgZVVbzJw4z0jRfW5kw4Hb26JDFjN7SRQF2RmRF0W9b3p5y4pHzcMW3mp2ww2JmTVDW4WR8796xMkb0N8Y1w5vmwMjpW2hmK1H1SLgTKW7rGFkW30HqzpW2Qx9Ld3Kyb_1W6sx4vl3P-gvmW2PGpgv5lG9FdW54K8YJ3hRJk5V21rxZ6PztxnW2xVpL6356D2BW1Vr_sn1QLnj3W41vf3838lh-DN2T9Nn6dfJHxW8HNqmq3Slm8BW5xR1kC3BfJZvW1RC8RZ3jTTTcW84Tx6t33BqM8W9kv9pd8yqFDjV-jdHm6NydP7W1SW0zC7TS6S8W77CD3_6nB3qNW4CKgh91DbJcXW3j_bJ95_lNs0W7qgjN_4JC_YrVdRJdf4ybDsPW5hRmny2s_ylTW7N_2WD1pl5JZW76LjcP4MgzhSW2S0Tnx8FQvsYVv6NRx54wNfnW9dhp687Zj83FW37yzh17l1ThvW57bzGj181TwF3nP21) is the place to be to exchange ideas & experiences with other cloud native enthusiasts from around the world. Join us **September 21-23**, virtually or in the beautiful city of Hamburg. **[Get Your Ticket Here](https://www.containerdays.io/tickets/?utm_medium=email&_hsmi=2&_hsenc=p2ANqtz-_GHnXGWQN9iD2xQbnZW4vZa3SC1iyuHj8ljSdRUyjkO0RBfVVcllAczGoS4GMBKx0MjxYOBx0ZStKqTjskbPCyqUbc-Q&utm_content=2&utm_source=hs_email)** ## Want to Know More? Check out our [website](https://it.t.hubspotemail.net/e2t/tc/VVzQSB29c75QMb_QjDwVWlVV5XFwB4tbF2bN8kT_z_3lGmcV1-WJV7CgCt2W3_1vQX5LwZ9WM_t03Szz-Y1W8F70gD7fzl86W1klGzm7Wn5VlW6C-K878xXGfbW4N8Q9T4tlhPNW4xPpjR4wTTn2N96rk7R5dnR7W4vngm46PpTJ2W3QG4GZ5YL60XW3jDQV-7_J0_hW8HCyfT5Fv2J_N7Nv547gKGXWW377lbc43RVDNW15pSPk92X1f1W3gpGtL7KHP29W9kl2xR31s9h3W8fLphY2qsPTh32KB1), follow us on [twitter](https://it.t.hubspotemail.net/e2t/tc/VVzQSB29c75QMb_QjDwVWlVV5XFwB4tbF2bN8kT_z_3lGmcV1-WJV7CgzPhMRkM7HXf_h8W5BCQcw6S3Yj3W4myYs-4TgytzW3pz2TX8_kbvwW6rN_vv7hNnl5W98pNhh48kGByW8c88tw25jBZSW6h2vZD7NShkwN6YBsWWNP4SHVNhPZZ99YDXqN26jpr6VcqfNV_SGcj3Nk7YbW87sfjN31tVv7N62NMRW_P7hSW8pvFdF18BtPqW5xyp4871ly1XW7cPslz87-QZnW6HWpVV42xjxq37kj1) or send us an email. --- ## Multi-cluster Services With Operators & KubeCarrier - **URL:** https://www.kubermatic.com/resources/how-to-deploy-multi-cluster-services-with-operators-and-kubecarrier/ - **Date:** 2026-03-17 - **Description:** Learn more about how to automate the management of applications and services lifecycle with Kubernetes Operators and KubeCarrier. # How to Deploy Multi-cluster Services With Operators and KubeCarrier? ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Watch the Recording of Our Webinar and Learn More About Multi-cluster Services and Their Interaction Complex application services consisting of multiple interconnected components can benefit from deployment in multiple Kubernetes clusters. However, this approach has some challenges. How can we interconnect the clusters so that the applications in different clusters can easily communicate with each other? How to allow for multi-tenancy and effortlessly spin up multiple instances of such services in the same cluster? In this session, we explain what this type of deployment looks like, with the help of Kubernetes operators, the KubeCarrier service hub and the Submariner cross-cluster connectivity provider. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Kubernetes Monitoring, Logging, and Alerting at Scale - **URL:** https://www.kubermatic.com/blog/how-to-implement-kubernetes-monitoring-logging-and-alerting-at-scale/ - **Date:** 2026-05-07 - **Description:** Find out how to implement a Monitoring, Logging, and Alerting stack (MLA) for a highly distributed platform, in a scalable and efficient manner. - **Categories:** Products, Community, Best Practices - **Tags:** KKP, Open Source Projects, Kubernetes - **Authors:** Rastislav Szabo As your Kubernetes installation grows in size, the day 2 operations of your clusters can quickly become a complex and sophisticated endeavour. When designing and developing Kubermatic Kubernetes Platform (KKP) as a multi-cloud and multi-cluster platform, we encountered a lot of challenges that required new strategies to make the operational tasks easier and more efficient.  In this post, we’ll look at how we implemented a Monitoring, Logging, and Alerting stack (MLA)  for a highly distributed platform, in a scalable and efficient manner.  To begin, let’s take a look at a typical MLA stack in a Kubernetes cluster: ![MLA stack in Kubernetes](/static/cloudops-summit_-mla-stack-in-kubernetes.png) Several different components may be deployed in a Kubernetes cluster, such as * Prometheus for scraping the application metrics * Loki for the application logs * Grafana for providing the user interface to access the logs and metrics, and the dashboards generated from them * Thanos and some cluster storage to provide long term storage of metrics and logs When you have more than one Kubernetes cluster, this process is usually repeated, with all of these components running in each cluster. ![MLA stack in two Kubernetes clusters ](/static/cloudops-summit_-mla_two-kubernetes-clusters.png) So far, so good. But when you start adding more clusters, it can quickly turn into an operational nightmare that is hard to manage. Installing and setting up the same components and version upgrades required across a lot of clusters is time consuming and inefficient.  ![Multi-cluster MLA stack in Kubernetes](/static/cloudops-summit_-mla_many-clusters.png) How do we make this easier? This was precisely the question we had to answer when building our Kubermatic Kubernetes Platform. And this is what we came up with.  Since KKP has a hierarchical architecture, in which the control plane components from multiple users run in a single seed cluster, we can build the MLA stack on top of this hierarchy. ![MLA in multiple Kubernetes clusters with KKP](/static/cloudops-summit_-mla_many-clusters-with-kkp.png) So, in the user clusters we just deploy the stateless components that stream the container metrics and logs to the seed cluster.  In the seed cluster, we then deploy all the complex components responsible for long-term storage and user interface, respecting multi-tenancy, so that every user can only access data in the cluster they have access.  But what if we are talking about an even more distributed environment with multiple seed clusters located at different locations?  In that case, we use a similar approach: the user clusters only contain the exporter applications and the seed clusters store all of the data.  ![MLA with multiple seed clusters](/static/cloudops-summit_-mla_multiple-seed-clusters.png) The data is still situated close to the user clusters, since we don’t want to stream all of that data across other locations. At the same time, we are still able to provide a single Grafana user interface that allows us to access the logs and metrics across all of the clusters and effectively streamline the entire hierarchy. Implementing our MLA stack for KKP in line with this approach brought us several benefits: * Easy installation in user clusters with a single click or an API flag, or can also be installed by default, into every cluster * Easy day 2 operations and upgrades of components in user clusters, because they are tiny and stateless * Low footprint for user clusters; particularly important for edge use cases running worker nodes on resource-constraint nodes * Single pane of glass for thousands of clusters, to access all logs and metrics across all clusters * Multi-tenancy support: * Authentication and authorization is integrated with KKP users, projects and roles * Per-tenant Grafana view for logs and metrics Or: * Global admin Grafana view for logs, metrics and alerts If you like to play around with Kubermatic Kubernetes Platform to manage your distributed Kubernetes clusters, check out our [documentation](https://docs.kubermatic.com/) to get you started. Also, feel free to be in touch via [Github](https://github.com/).  **Learn More** * Read our blog post: [The Complete Guide to Kubernetes Metrics](https://www.kubermatic.com/blog/the-complete-guide-to-kubernetes-metrics/) * Video: [How to Write Software That Sets up Kubernetes Anywhere](https://www.kubermatic.com/resources/how-to-write-software-that-sets-up-kubernetes-anywhere/) --- ## PersistentVolumes and PersistentVolumeClaims: Intro - **URL:** https://www.kubermatic.com/blog/keeping-the-state-of-apps-4-persistentvolumes-and-persistentvolum/ - **Date:** 2026-05-07 - **Description:** Learn more about data persistence using PersistentVolumes and PersistentVolumeClaims. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Seyi Ewegbemi Previously in this series, we looked at [volumes and volumeMounts in Kubernetes](https://www.kubermatic.com/blog/keeping-the-state-of-apps-1-introduction-to-volume-and-volumemounts/). Now, we will take a step further and introduce two other Kubernetes objects related to data persistence and preservation. In this part of the series, you will learn about persistent storage in Kubernetes, specifically **PersistentVolumes (PVs)** and **PersistentVolumeClaims (PVCs)**. We will cover the following topics, including hands-on practice on the functionalities of these concepts: * What are PersistentVolumes and PersistentVolumeClaims? * How and by whom are PersistentVolumes defined? * How do PersistentVolumes differ from Volumes? * How are PersistentVolumes and PersistentVolumeClaims created? * How and by whom is Persistent storage requested using PersistentVolumeClaims? ## **Kubernetes PersistentVolumes (PVs) and PersistentVolumeClaims (PVCs)** Storage management is essential in Kubernetes, especially in large environments where many users deploy multiple Pods. The users in this environment often need to configure storage for each Pod individually, and any changes to existing applications must be applied to all Pods sequentially. This process can be time-consuming. To address this issue and separate how storage is provisioned from how it is consumed, we use PersistentVolumes (PVs) and PersistentVolumeClaims (PVCs). ### What are PersistentVolumes and PersistentVolumeClaims? A **PersistentVolume (PV)** in Kubernetes is a pool of pre-provisioned storage resources in a Kubernetes cluster, that can be used across different user environments. Its lifecycle is separate from a Pod that uses the PersistentVolume. A **PersistentVolumeClaim (PVC)**, is a process of storage requests from PVs by the users in Kubernetes. Kubernetes binds PVs with the PVCs based on the request and property set on those PVs. Kubernetes searches for PVs that correspond to the PVCs’ requested capacity and specified properties, so that each PVC can bind to a single PV.  When multiple matches are found, labels and selectors can be employed to bind a PVC to the most appropriate or specific PV. This approach prevents situations where a small PVC inadvertently binds to a larger PV, as PVs and PVCs are designed to have a one-to-one relationship. If a small PVC binds to a large PV, the unused capacity of the PV becomes inaccessible to other users. By using labels and selectors, you can ensure that each PVC is matched with the most suitable PV, optimizing resource utilization and preventing wasted storage space. **NOTE:** Both the PVCs and the Pod using them must be in the same namespace. ## **The Difference Between PersistentVolumes and PersistentVolumeClaims in Kubernetes** PersistentVolumes and PersistentVolumeClaims in Kubernetes differ in provisioning, functionalities, and the person responsible for creating them, specifically : * PVs are created by the cluster administrator or dynamically by Kubernetes, whereas users/developers create PVCs. * PVs are cluster resources provisioned by an administrator, whereas PVCs are a user’s request for storage and resources.  * PVCs consume PVs resources, but not vice versa. * A PV is similar to a node in terms of cluster resources, while a PVC is like a Pod in the context of cluster resource consumption. ![PVs and PVCs architecture](/static/pvs-and-pvcs-architecture.jpg) ## **Difference Between Volumes and PersistentVolumes** Volumes and PersistentVolumes differ in the following ways: * A Kubernetes Volume separates storage from a container but binds it to a Pod, while PVs separate storage from a Pod.  * The lifecycle of a Volume is dependent on the Pod using it, while the lifecycle of a PV is not. * A Volume enables safe container restart and allows sharing of data across containers, whereas a PV enables safe Pod termination or restart.  * A separate manifest YAML file is needed to create a PV, but it is not required for a volume. ## **PersistentVolumes and PersistentVolumeClaims Lifecycle** The communication between Kubernetes PVs and PVCs consists of the following stages: * **Provisioning:** This is the process of creating a storage volume, which can be done **statically** or **dynamically**. * **Static:** The static way of provisioning a storage volume is when  PVs are created before PVCs by an Administrator and exist in the Kubernetes API, waiting to be claimed by a user’s storage request, using PVC. * **Dynamic:**  The dynamic way of storage provisioning involves creating PVs automatically, using StorageClass instead of manual provisioning of PersistentVolumes. Kubernetes will dynamically provision a volume specifically for this storage request, with the help of a StorageClass. (More about StorageClass and how it is used to provision Kubernetes PVs dynamically in the next part of this series). * **Binding:** When an Administrator has provisioned Kubernetes PVs and users make a specific amount of storage requests (PVCs), a control loop in the master finds a matching PV and binds them together. If a matching volume does not exist, the claim will remain unbound until a volume match is created. * **Using:** Pods use claims as volumes. The Kubernetes API checks the claim to find a bound PV and mounts it in the Pod for the users. When a claim is already bound to a PV, the bind remains unchanged as long as the user wants it. So user A’s bound PV can not be taken over by user B, if it is still in use by user A. * **Reclaiming:** When a user is done with the volume usage, the resources must be freed up by deleting the PVC objects from Kubernetes. This practice will free the PV from the PVC, allowing reclamation of the resources, making it available for future use. What happens to the volumes afterwards is determined by the PersistentVolumeReclaimPolicy (PVRP) value specified in the configuration file. The PVRP provides three options of what you can do to a PersistentVolume after the claim has been deleted:  **retain**, **delete**, or **recycle**. * **Retain:** This is the default reclaim policy. It is a process that allows manual deletion of the PV by the Administrator. When a PVC is deleted, the PV remains intact, including its data, thus making it unavailable for use by another claim.  However, the Administrator can still manually reclaim the PersistentVolume. * **Delete:** When the reclaim policy is set to delete, the PV deletes automatically when the PVC is deleted and makes the space available. It is important to note that the dynamically provisioned PVs inherit the reclaim policy of their StorageClass, which defaults to **Delete**. * **Recycle:** This type of reclaim policy will scrub the data in the PV and make it available for another claim. ## **How to Create a PersistentVolume** The following steps will guide you on how to create a PersistentVolume and how to use it in a Pod. Before continuing, it is imperative to have a basic knowledge of [volume, volumeMounts, and volume types](https://www.kubermatic.com/blog/keeping-the-state-of-apps-1-introduction-to-volume-and-volumemounts/) such as hostPath, emptyDir, among others, in order to effectively follow this hands-on practice. A running Kubernetes cluster and a kubectl command-line tool must be configured to talk to the cluster. If you do not have this, you can simply create a Kubernetes cluster on any environment with [KubeOne](https://github.com/kubermatic/kubeone#getting-started). Refer to [Getting Started](https://github.com/kubermatic/kubeone#getting-started) for instructions. Alternatively, you can go to the [Kubernetes playground](https://labs.play-with-k8s.com/) to practice. In that case, you might also need a cloud provider (GKE, AWS, etc.) access or credentials to provision storage. Follow the below steps to create a PersistentVolume (PV): **Step 1:** Create the YAML file. ```yaml $ vim pv-config.yaml ``` **Step 2:** Copy and paste the below configuration file into the YAML manifest file created above. ```yaml apiVersion: v1 kind: PersistentVolume metadata: name: my-volume spec: capacity: storage: 3Gi accessModes: - ReadWriteOnce hostPath: path: "/app/data" ``` The configuration above shows properties with different functionalities. In addition to the properties from the previous Kubernetes objects exercises, let’s look at **accessModes**, **capacity**, and **storage** **properties**: * **accessModes**: This property defines how a PV should be mounted on the host. The value can be **ReadWriteOnce**, **ReadOnlyMany**, or **ReadWriteMany**. Below is a basic description of  these values: * **ReadWriteOnce:** You can mount the PV as read-write by a single node. * **ReadOnlyMany:** You can mount the PV as read-only by multiple nodes. * **ReadWriteMany:** You can mount the PV as read-write by multiple nodes. * **capacity.storage:** This property is used to set the amount of storage needed for the volume. **Step 3:** Create the Persistent Volume using `kubectl create` command. ```bash $ kubectl create -f pv-config.yaml persistentvolume/my-volume created ``` **Step 4:** Check the created PV to see if it is available. ```bash $ kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE my-volume 3Gi RWO Retain Available ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ 60s ``` **Step 5:** Check the description of the PersistentVolume by running `kubectl describe` command. ```bash $ kubectl describe pv my-volume Labels: <none> Annotations: <none> Finalizers: [kubernetes.io/pv-protection] StorageClass: Status: Available Claim: Reclaim Policy: Retain Access Modes: RWO VolumeMode: Filesystem Capacity: 3Gi Node Affinity: <none> Message: Source: Type: HostPath (bare host directory volume) Path: /app/data HostPathType: Events: <none> ``` As seen above, the PersistentVolume is available and ready to serve a PVC storage request. The status will change from **available** to **bound** when it has been claimed. **NOTE:** It is not advisable to use the hostpath volume type in a production environment. ## **How to Create a PersistentVolumeClaim (PVC) in Kubernetes** Now that the PersistentVolume has been successfully created, the next step is to create a PVC that will claim the volume. Creating a PersistentVolumeClaim is similar to the method used to create the PersistentVolume above, with a few differences in terms of its properties and values. The value of the kind property will be **PersistentVolumeClaim**. The **resources.request.storage** field will also be added, and the value will be the provisioned PV capacity value (so 3Gi in our case). The following steps will guide you on how to create a PersistentVolumeClaim (PVC) in Kubernetes: Your configuration will look like the manifest file below: ```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-claim spec: accessModes: - ReadWriteOnce resources: requests: storage: 3Gi ``` **Step 1:** Create a YAML file. ```yaml $ vim pvc-config.yaml ``` **Step 2:** Copy and paste the above configuration file into the YAML file created above. **Step 3:** Create the PVC by running `kubectl create` command. ```bash $ kubectl create -f pvc-config.yaml persistentvolumeclaim/my-claim created ``` **Step 4:** Check the status of the PVC by running `kubectl get` command. ```bash $ kubectl get pvc my-claim NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE my-claim Bound my-volume 3Gi RWO 7m ``` **Step 5:** Check the description of the PVC. ```bash $ kubectl describe pvc my-claim Name: my-claim Namespace: default StorageClass: Status: Bound Volume: my-volume Labels: <none> Annotations: pv.kubernetes.io/bind-completed: yes pv.kubernetes.io/bound-by-controller: yes Finalizers: [kubernetes.io/pvc-protection] Capacity: 3Gi Access Modes: RWO VolumeMode: Filesystem Mounted By: <none> Events: <none> ``` As shown above, the status indicates a **"Bound"** state, which means the PVC and PV are now bound together. Now, check the status of the PV once again with `kubectl get` command. ```bash $ kubectl get pv my-volume NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM ⠀⠀⠀STORAGECLASS REASON AGE my-volume 3Gi RWO Retain Bound default/my-claim ⠀⠀⠀ 11m ``` The output shows that the status has changed from **"available"** when it is not yet bound to **"Bound"** because the PV has been claimed by the created PVC. **Step 6:** Delete the PVC using `kubectl delete` command. ```bash $ kubectl delete pvc my-claim persistentvolumeclaim "my-claim" deleted ``` **Step 7:** Check both the PVC and PV status with `kubectl get` command. ```bash $ kubectl get pvc my-claim No resources found in default namespace. ``` ```bash $ kubectl get pv my-volume NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM ⠀⠀⠀STORAGECLASS REASON AGE my-volume 3Gi RWO Retain Released default/my-claim ⠀⠀ 21m ``` The output shows that the Kubernetes PV status has now changed from a **"Bound"** to a **"Released"** state, after the PVC is deleted. ## **PersistentVolumes States** A PV has different states, can be in any of these, and each has its own meaning, described as follows: * **Available:** The PV is free and not yet claimed or bounded. * **Bound:** The PV has been claimed or bounded. * **Released:** The bounded PVC has been deleted, and the PV is free from its previous bounded state. * **Failed:** The PV has failed its automatic reclamation. ## **PersistentVolumeClaims States** Each PVC, like the PV, has its own states that represent its current status. * **Bound**: The PVC is bound to a PV. * **Pending:** The PVC can not bind to a PV. This could be due to a higher storage request than the PV capacity, or the PV accessMode value is different from that of the PVC, etc. ## **How to Use PersistentVolumeClaim in a Pod** A Pod can access storage with the help of a PVC, which will be used as a volume. PVC can be used in a Pod by first declaring a **"volumes"** property in the Pod manifest file and specifying the claim name under the declared volume type **"persistentVolumeClaim"** property. It is essential that both the PVC and the Pod using it exist in the same namespace. This will allow the cluster to find the claim in the Pod’s namespace and use it to access the PersistentVolume that is bound to the PVC. Once created, the applications in the containers can read and write into the storage.The complete configuration file will look like this: ```yaml apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: stclass-test image: nginx volumeMounts: - mountPath: "/app/data" name: my-volume volumes: - name: my-volume persistentVolumeClaim: claimName: my-claim ``` The below steps will guide you through how to use a claim in a Pod. The PV and PVC have to be provisioned before creating the Pod. The claim name inside the Pod must also match the claim name in the running PVC. **Step 1:** Create a YAML file. ```yaml $ vim pvc-pod.yaml ``` **Step 2:** Copy and paste the above Pod manifest file into the YAML file created above and create the Pod with `kubectl create` command. ```yaml $ kubectl create -f pvc-pod.yaml pod/my-pod created ``` **Step 3:** Check the status and the description of the Pod. ```bash $ kubectl get pod my-pod NAME READY STATUS RESTARTS AGE my-pod 1/1 Running 0 6m50s ``` ```bash $ kubectl describe pod my-pod Name: my-pod Namespace: default Priority: 0 Node: node01/172.17.0.57 Start Time: Tue, 01 Dec 2020 11:44:08 +0000 Labels: <none> Annotations: <none> Status: Running IP: 10.244.1.2 IPs: IP: 10.244.1.2 Volumes: my-volume: Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace) ClaimName: my-claim ReadOnly: false default-token-nlmxj: Type: Secret (a volume populated by a Secret) SecretName: default-token-nlmxj Optional: false QoS Class: BestEffort ``` **Step 4:** Exec into the Pod to test the PVC use case. ```bash $ kubectl exec -it my-pod -- bin/bash root@my-pod:/# ``` **Step 5:** Use `df -h` together with the path to confirm the mount point. ```txt root@my-pod:/# df -h /app/data Filesystem Size Used Avail Use% Mountedon /dev/mapper/host01--vg-root 191G 22G 159G 13% /app/data ``` **Step 6:** Change into the mount directory and create a file using `echo` command. ```txt root@my-pod:/# cd /app/data root@my-pod:/app/data# echo "I love Kubermatic" > file.txt ``` **Step 7:** Check the created file and data using `ls` and `cat` **commands**, then exit the Pod once this has been confirmed. ```txt root@my-pod:/app/data# ls file.txt root@my-pod:/app/data# cat file.txt "I love Kubermatic" root@my-pod:/app/data# exit ``` **Step 8:** Delete and recreate the Pod. ```txt $ kubectl delete pod my-pod pod "my-pod" deleted $ kubectl get pods No resources found in default namespace. ``` Recreate the Pod and check the status: ```yaml $ kubectl create -f pvc-pod.yaml pod/my-pod created $ kubectl get pod my-pod NAME READY STATUS RESTARTS AGE my-pod 1/1 Running 0 5s ``` **Step 9:** Exec into the Pod and check the previous file and data created if they exist in the new Pod. ```bash $ kubectl exec -it my-pod -- bin/bash root@my-pod:/# df -h /app/data Filesystem Size Used Avail Use% Mountedon /dev/mapper/host01--vg-root 191G 22G 159G 13% /app/data root@my-pod:/# cd /app/data root@my-pod:/app/data# ls file.txt root@my-pod:/app/data# cat file.txt "I love Kubermatic" ``` You can see that the file and data created in the deleted Pod above are still there and were taken up by the new Pod. **Summary:** PersistentVolumes and PersistentVolumeClaims are Kubernetes objects that work in tandem to give your Kubernetes applications a higher level of persistence, either statically or dynamically, with the help of StorageClass. In this part of the series, you learned how to create PersistentVolumes and PersistentVolumeClaims, how they are defined, and how PersistentVolumes differ from Volumes. In the next part of our series, we will look at another way to persist data in Kubernetes with StorageClass. You’ll see its functionalities in action, why it’s needed, and how it can be used in a Pod together with a claim. We’d love to hear from you!  Please [contact us](mailto:marketing@kubermatic.com) with any thoughts or questions you might have about PersistentVolumes and PersistentVolumeClaims. ## **Learn More** * Learn more about [Kubernetes Persistent Volumes and Kubernetes Persistent Volume Claim](https://kubernetes.io/docs/concepts/storage/persistent-volumes/). * Read more on [how to bind PersistentVolumes](https://docs.openshift.com/container-platform/3.3/install_config/storage_examples/binding_pv_by_label.html). * Watch Philipp Reisner's talk on [Persistent Volumes for Kubernetes](https://www.youtube.com/watch?v=WWiBwMZHZDY). --- ## Why Implementing Kubernetes Operators Is a Good Idea! - **URL:** https://www.kubermatic.com/blog/why-implementing-kubernetes-operators-is-a-good-idea/ - **Date:** 2026-05-07 - **Description:** Learn more about Kubernetes Operators with Kubermatic Kubernetes Platform and KubeCarrier - **Categories:** Products, Community, Best Practices - **Tags:** KKP, Kubernetes, Open Source Projects - **Authors:** Jiacheng Xu There are so many environments that operational tasks and applications have to be managed in today, it can be a real challenge. Implementing cloud native Operators are a great way to improve efficiencies by providing the tools to automate these processes. In this blog post, you’ll learn more about what Kubernetes Operators are and the benefits of adding them. [Operators](https://www.kubermatic.com/blog/why-kubernetes-operators-will-bring-you-to-the-next-level-of-automation/) extend the power of Kubernetes to a wide range of applications, serve as templates for automating application management, and improve scalability and repeatability – critical for deploying stateful applications in a truly cloud native way.  Kubernetes is well known and selected, time after time, for its ability to significantly reduce the operational burden of managing applications and services in a multi-cloud infrastructure. Kubernetes Operators deliver outstanding performance by automating the entire lifecycle of the applications and services it manages.  ## What Are Kubernetes Operators? A Kubernetes Operator is a way of automating the management of an application, including its packaging and deployment on Kubernetes, using the kubectl tooling and the Kubernetes API (application programming interface). It expands the utilities of the Kubernetes API by automating the creation, configuration and management of both stateful and stateless applications, no matter how complex. By including domain or application-specific knowledge, along with the basic concepts of resources and controllers, this method fully automates the entire lifecycle of the software it manages. It monitors the application, backs up data, deploys failure recovery and performs upgrades automatically. By eliminating complex and problematic manual tasks, Kubernetes Operators make these processes consistent, repeatable and scalable, reducing errors and providing maximum application performance. ![What are Kubernetes Operators](/static/graphic_what-are-kubernetes-operators.png) ## Why Implement Operators? Implementing Operators has several benefits. **Automation advantages** * Automates operational tasks, normally managed by human operators, including * Deployments * Upgrades * Backups * Failure recovery **Additional advantages** * Makes applications more Kubernetes-native (lots of Kubernetes features, right out of the box) * Interacts with your applications using Kubernetes APIs and kubectl toolings * Tests application operations and eliminates human error in application lifecycle management * Simplifies application management in multi and hybrid cloud environments * Enhanced compatibility means Operators can work across different types of distributions  So, let’s have a look at the two types of Operators… ## Namespace-Scoped and Cluster-Scoped Operators 1. **Namespace-Scoped Operators** * Manages resources in a single Namespace Benefits: * Flexible to run different versions of an operator independently in a cluster * Helpful in dev or single cluster environments 2. **Cluster-Scoped Operators** * Manages resources cluster-wide * Single instance of an operator in a Kubernetes cluster * Recommended for highly distributed environments Benefits: * Easier to manage 1000’s of clusters * Significantly reduces resources required in multi-tenant environments (so they can be deployed in other, more important areas!) ## Operators With Kubermatic Kubernetes Platform and KubeCarrier Kubernetes Operators are leveraged by [KubeCarrier](https://github.com/kubermatic/kubecarrier), our open source hub for managing applications and services across multiple Kubernetes Clusters, to automate the provisioning and management lifecycle of all services, applications and API-accessible hardware devices. As cloud native adoption accelerates, operations teams are confronted with the complexities of service management across multiple clusters, clouds, and regions. They struggle with enterprise-grade compliance and the operational burden involved. KubeCarrier addresses these complexities by harnessing Operators and the Kubernetes API  into a central framework, allowing enterprises and service providers to deliver cloud native service management from one multi-cloud, multi-cluster hub. Internal or external customers can immediately deploy the cloud native software and services they need, including databases, data stores, monitoring, service meshes, and other Kubernetes tooling. With [Kubermatic Kubernetes Platform](https://www.kubermatic.com/products/kubermatic-kubernetes-platform/), we extend the Operator model beyond applications to manage the clusters themselves – essentially, we are using Kubernetes to operate Kubernetes.  We provide a central service hub that leverages the KubeCarrier system and cluster-scoped Kubernetes Operators, to provide multi-tenancy support through resource isolation in Kubernetes Namespace. Cluster-scoped Operators can manage service instances across multiple Namespaces, which reduces the maintenance burden and complexities of service management across multiple clusters, clouds, and regions. ![Kubernetes Operators With Kubermatic Kubernetes Platform](/static/graphic_kubernetes-operators-with-kubermatic-kubernetes-platform.png) Are you ready to simplify, automate and improve the management of your applications, tasks and resources in your single or multi-cluster container environment? [Contact us](https://www.kubermatic.com/contact-us/)! ## Find Out More Here * Blog Post: [Getting Started With KubeCarrier](https://www.kubermatic.com/blog/getting-started-with-kubecarrier/) * Documentation: [About Kubernetes Operators](https://docs.kubermatic.com/kubecarrier/v0.3/references/kubernetes-operators/) * Documentation: [KuberCarrier](https://docs.kubermatic.com/kubecarrier/v0.3/) * Demo: [Automate Your Clusters Across Multi-Cloud with Kubermatic Kubernetes Platform](https://www.kubermatic.com/resources/automate-your-clusters-across-multi-cloud-with-kkp/) --- ## Kubernetes Deployments: An Introduction - **URL:** https://www.kubermatic.com/blog/introduction-to-kubernetes-deployment/ - **Date:** 2026-05-07 - **Description:** Learn how to manage Kubernetes applications using Kubernetes Deployment. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Seyi Ewegbemi In the last part of this series, you learnt about ReplicaSet and its functionalities to make the management of Kubernetes applications easier. We will take a step further in this part by introducing you to Kubernetes Deployment. You will learn how to use Deployment to create a Pod, upgrade or downgrade your application with zero downtime and other Deployment actions using hands-on practice in this part of the series. Questions like why do we need Deployment, and the relationship between Deployment and ReplicaSet will be answered in this section. ## What is a Deployment in Kubernetes? A Deployment is one of the Kubernetes objects that is used to manage Pods via ReplicaSets in a declarative way. It provides updates, control as well as rollback functionalities. This means you can update or downgrade an application to the desired version without experiencing a user blackout as well as roll back to the previous version in case the new version is unstable or filled with bugs. Also, using a declarative management style for Deployment allows it to bring the desired states of the defined application in a YAML file into reality. **Deployment Features** A Deployment has the following features: * Create a ReplicaSet and Pods * Update a ReplicaSet * Scale-up/down a Deployment * Pause/continue a Deployment * Rollback to the previous version * Clean up unwanted ReplicaSets **Creating a Kubernetes Deployment** We will create a Deployment that will roll out a ReplicaSet to bring up three instances of an nginx Pod. You must have a running Kubernetes cluster with the kubectl command-line tool configured and connected to it to follow this exercise. Check [KubeOne doc](https://docs.kubermatic.com/kubeone/v1.2/quick_start/) for a guide on getting a running Kubernetes cluster using [KubeOne.](https://github.com/kubermatic/kubeone#getting-started) Basic knowledge of Pod and ReplicaSet is suggested to follow this hands-on practice. Creating a Deployment is the same as creating a ReplicaSet, but Deployment is the **kind** `property’s value`. Moreso, **strategy** `property and values` need to be added to the manifest file. **Step1:** Create a YAML manifest file named `my-deployment.yaml` using vim on the command line. ```bash $ vim my-deployment.yaml ``` **Step2:** Copy, paste, and save the configuration below into your YAML file. ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: my-deployment spec: replicas: 3 strategy: type: Recreate selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: containers: - name: my-deployment-container image: nginx ``` The above configuration file defined a Deployment object named `my-deployment` under the `metadata.name` property with `Deployment` as the value of its `kind` property. ```bash spec.replicas: ## the Deployment will create the number of replicated Pods specified in this field spec.strategy.type: ## the desired strategy type is declared in this field The strategy is a child of the spec while type is a child of the strategy and grandchild of spec spec.selector: ## this field defines how the Deployment determines which Pods to manage spec.containers: ## the container name and image are declared in this field ``` **NOTE**: The file must be correctly indented to avoid errors. **Step2:** Run this command to create a Deployment: ```bash $ kubectl create -f my-deployment.yaml deployment.apps/my-deployment created ``` **Step3:** Check the Deployment status to see if it has been created. ```bash $ kubectl get deployments my-deployment NAME READY UP-TO-DATE AVAILABLE AGE my-deployment 0/3 0 0 2s ``` When you see an output like this, it means the Deployment is still being created. Wait for a few seconds and run the `kubectl get` command once again. Once it is ready, the output will look like this. ```bash $ kubectl get deployment my-deployment NAME READY UP-TO-DATE AVAILABLE AGE my-deployment 3/3 3 3 95s ``` The status output is further broken down below: ```bash Name: ## Shows the name of the Deployment as declared in the manifest file Ready: ## This shows the number of replicas that are ready for use. In this case, all 3 out of 3 are ready for use Up-To-Date: ## This shows the up-to-date number of replicas out of the desired number declared in the YAML file Available: ## This shows the number of replicas that are available for use Age: ## Shows the duration the application has been running ``` **Step 4:** Check the Pod status to confirm if the desired number of Pods are running. ```bash $ kubectl get pods NAME READY STATUS RESTARTS AGE my-deployment-6b9b97d749-4fv5n 1/1 Running 0 3m58s my-deployment-6b9b97d749-lscf2 1/1 Running 0 3m58s my-deployment-6b9b97d749-p422m 1/1 Running 0 3m58s ``` To delete one of the instances of the Pod: ```bash $ kubectl delete pod my-deployment-6b9b97d749-4fv5n pod "my-deployment-6b9b97d749-4fv5n" deleted ``` Check if it has been deleted. ```bash $kubectl get pods NAME READY STATUS RESTARTS AGE my-deployment-6b9b97d749-lscf2 1/1 Running 0 8m3s my-deployment-6b9b97d749-p422m 1/1 Running 0 8m3s my-deployment-6b9b97d749-t2zmh 1/1 Running 0 54s ``` As seen above, three instances of Pod are running while the old ones have already been terminated or deleted. This was made possible with the help of ReplicaSet. One of the importance of ReplicaSet in a Deployment is to ensure that the desire instances of a Pod are up-to-date and are continually running on the cluster. The number of running instances depends on the `ReplicaSet value` declared in the YAML manifest file. To view the description of the Deployment: ```bash $ kubectl describe deployments my-deployment Name: my-deployment Namespace: default CreationTimestamp: Mon, 27 Jul 2020 17:22:40 +0000 Labels: <none> Annotations: deployment.kubernetes.io/revision: 1 Selector: app=my-app Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable StrategyType: Recreate MinReadySeconds: 0 Pod Template: Labels: app=my-app Containers: my-deployment-container: Image: nginx Port: <none> Host Port: <none> Environment: <none> Mounts: <none> Volumes: <none> Conditions: Type Status Reason ---- ------ ------ Available True MinimumReplicasAvailable Progressing True NewReplicaSetAvailable OldReplicaSets: <none> NewReplicaSet: my-deployment-97cfc859f (3/3 replicas created) Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ScalingReplicaSet 7m25s deployment-controller Scaled up replica set my-deployment-97cfc859f to 3 ``` The Deployment description is further expantiated below: ```bash Name: ## The name of the Deployment as specified in the manifest file. Namespace: ## It is always a default if no namespace is specified in the manifest file. Replicaset: ## The desired number of replicas specified in the manifest file. Strategy.recreate: ## The strategy to be used for the Deployment. You can find more info on Deployment strategy in the next part of this series. Containers.image: ## This field specifies the container and container image names. Events: ## Shows the Deployment activities since it was created. ``` ## Updating a Kubernetes Deployment You can edit a Deployment by changing the container image from one version to the other, decreasing or increasing the number of instances by changing the ReplicaSet value. etc. For example, the container image `nginx` we have been using in our exercises has many versions. When no version is specified in the manifest YAML file, the latest version will be pulled from the image repository. We will change the current image version to another as an example. A Deployment can be updated to use a new image in two ways: **Method 1:** You can pass the new image tag directly to the Deployment using flags with the `kubectl command-line tool`. We will change the `nginx` in our manifest file to use the `nginx:1.18.0` version. ```bash $kubectl --record deployment.apps/my-deployment set image deployment.v1.apps/my-deployment my-deployment-container=nginx:1.18.0 deployment.apps/my-deployment image updated or $kubectl set image deployment/my-deployment my-deployment-container=nginx:1.18.0 --record deployment.apps/my-deployment image updated ``` In the above command, `my-deployment` is the name of the Deployment and `my-deployment-container` is the container name as declared in the YAML file. Check the description again and compare it to the original configuration. ```yaml $kubectl describe deployment my-deployment Name: my-deployment Namespace: default CreationTimestamp: Mon, 27 Jul 2020 17:22:40 +0000 Labels: <none> Annotations: deployment.kubernetes.io/revision: 2 kubernetes.io/change-cause: kubectl deployment.apps/my-deployment set image deployment.v1.apps/my-deployment my-deployment-container=nginx:1.18.0 --record=true Selector: app=my-app Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable StrategyType: Recreate MinReadySeconds: 0 Pod Template: Labels: app=my-app Containers: my-deployment-container: Image: nginx:1.18.0 Port: <none> Host Port: <none> Environment: <none> Mounts: <none> Volumes: <none> Conditions: Type Status Reason ---- ------ ------ Available True MinimumReplicasAvailable Progressing True NewReplicaSetAvailable OldReplicaSets: <none> NewReplicaSet: my-deployment-79f645dc59 (3/3 replicas created) Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ScalingReplicaSet 12m deployment-controller Scaled up replica set my-deployment-97cfc859f to 3 Normal ScalingReplicaSet 32s deployment-controller Scaled down replica set my-deployment-97cfc859f to 0 Normal ScalingReplicaSet 23s deployment-controller Scaled up replica set my-deployment-79f645dc59 to 3 ``` Comparing the description outputs of the original and updated versions, we have changed the image version from `nginx` to `nginx:1.18.0` as it is stated in the Pod template. In addition, there are more events compared to before the update describing the internal processes of the rolling update. It shows here that the Deployment updated the Pods by creating and scaling a new ReplicaSet of 3 replicas and destroying the old one. Check the ReplicaSet status for clarity. ```bash $kubectl get replicaset NAME DESIRED CURRENT READY AGE my-deployment-79f645dc59 3 3 3 76s my-deployment-97cfc859f 0 0 0 4m53s ``` **Method 2:** Directly editing the manifest YAML file. Alternatively, you can edit the Deployment YAML file and change the current image version from `nginx:1.18.0` to `nginx:1.19.1` by running the below command then save and exit the terminal: ```bash $kubectl edit deployment.v1.apps/my-deployment deployment.apps/my-deployment edited ``` Check the status of the Deployment to see that we still have 3 deployments ready. ```yaml $kubectl get deployment my-deployment NAME READY UP-TO-DATE AVAILABLE AGE my-deployment 3/3 3 3 29m ``` Check the description of the Deployment to see that the image has been updated. ```yaml $kubectl describe deployment my-deployment Name: my-deployment Namespace: default CreationTimestamp: Mon, 27 Jul 2020 18:18:58 +0000 Labels: <none> Annotations: deployment.kubernetes.io/revision: 3 kubernetes.io/change-cause: kubectl set image deployment/my-deployment my-deployment-container=nginx:1.18.0 --record=true Selector: app=my-app Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable StrategyType: Recreate MinReadySeconds: 0 Pod Template: Labels: app=my-app Containers: my-deployment-container: Image: nginx:1.19.1 Port: <none> Host Port: <none> Environment: <none> Mounts: <none> Volumes: <none> Conditions: Type Status Reason ---- ------ ------ Available True MinimumReplicasAvailable Progressing True NewReplicaSetAvailable OldReplicaSets: <none> NewReplicaSet: my-deployment-5997f87f5f (3/3 replicas created) Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ScalingReplicaSet 30m deployment-controller Scaled up replica set my-deployment-97cfc859f to 3 Normal ScalingReplicaSet 27m deployment-controller Scaled down replica set my-deployment-97cfc859f to 0 Normal ScalingReplicaSet 27m deployment-controller Scaled up replica set my-deployment-79f645dc59 to 3 Normal ScalingReplicaSet 2m39s deployment-controller Scaled down replica set my-deployment-79f645dc59 to 0 Normal ScalingReplicaSet 2m31s deployment-controller Scaled up replica set my-deployment-5997f87f5f to 3 ``` Finally, checking the ReplicaSet status, you can see that we created a new Deployment and scaled it up to 3 replicas while the old one was scaled down to 0. Check the ReplicaSet status: ```bash $ kubectl get replicaset NAME DESIRED CURRENT READY AGE my-deployment-5997f87f5f 3 3 3 72s my-deployment-79f645dc59 0 0 0 25m my-deployment-97cfc859f 0 0 0 29m ``` **Clean-up:** Delete the Deployment using the `kubectl delete` command. ## Summary: The exercises and concepts we walked you through demonstrate how using Kubernetes Deployments rather than Pods to manage your application is one of the best Kubernetes practices. Deployments make the scaling up and down of Pod via ReplicaSet easier and flexible.  Next in our series, we will look at Deployment strategies, types, and their functionalities. We encourage you to [contact us](mailto:marketing@kubermatic.com) with any questions you have. ## **Learn More** * Learn more about Kubernetes Deployment on [Kubernetes official](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) website * Read more on [rolling update Deployment here](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment) --- ## Kubermatic News for May 2021 - **URL:** https://www.kubermatic.com/blog/kubermatic-news-for-may/ - **Date:** 2026-05-07 - **Description:** Learn more about Kubermatic Kubernetes Platform 2.17 release, multi-cloud solutions and ContainerDays Hybrid 2021. - **Categories:** Company - **Tags:** Announcements - **Authors:** Sebastian Scheele The discoveries from this year’s KubeCon Europe as well as the results in the [Flexera 2021 State of the Cloud Report](https://it.t.hubspotemail.net/e2t/tc/VXcF9D8PRXRzW1b8Jr54HTZ0YW6L2xF54r_HNQN4jRWdp9ghWyV7Wycr7CgXk2Vx6WCH4NqzKDW3rdMgK1_2xQPW3-Hq7h4W0TbNN5wK7ptv2VVmW2CQ82X7ZmbGfVp1x-Y1wxhjKW6TQf0B5QG5wFW1kZds_1KxZjDW381V0r3yvt4kW7hD2qT6yHnd2W196Bvv1S57KzW8WxpHs7JHWW_W4ZP0gC2JNC3XW3CdySR3q7JqYW3RDFH83nhKgQW6rT3nf83bm_KN7ptMGqZZnb3W2fcCLg3R5y-rW8SdP2r3FGMf8W8TJM883S89q-W8Jx6Wj20V4NlW2ygnT_7MKwzBMlgmvvr1N--W1y9zQh8RQqz1VhW19z91lYRsW158B9N58DYBQW8G1DPx8ZxtsxW88PtVX22MH7vN6KZvz9PkJrzW937Brr4JDcdKN7T1b4_lBBwGW7lptHF6bMmF9W3Ydkkw8YM_RhVKqJ0T5p1T6SW3tD1sK47lr6WW7w04DZ1l_fL4W1RQTDp2j36ktN5nLpjzD0Z5QW8VRDwj3_1DBRW4YJ5gd157vT0N2jtDbQKjhS1W8yBY8q4v2Q2HW8GtN1t2FWX5ZW7-CKvK7kR3LrW59dHd72l5PG4N7D6l_kfg2GHW3JCNbz6bBGzcW6lp1056hqyZxVMlx-y3qfw2wW5Hbz6W7VH8dFW6b8Bbt7Vr4jwMHxdsVhqgYtW6D5yyG4kNFLhW6gZt7d1t8sf6W3DHZ2S8qpXsYW4gl7BK1CcBjZN5Q1FPV8D1CXW38p6w-3b6xGkVNMX8C7PbRyPW9cKBbN3tnsS-V9mrtD5cxXtwW6Yk8VN5pC5TqW2813XR4m85LtW6YvhJV6BXWlYW8z58J16l1QmdW7KkfTL1P7YknW5pX14d6FhNj9W7yv2DB27lmsCW4QqcG36yR5g9W8L5nNN6g9fQDW6fhjCp3wx0gMW7GG3Yx6TxfDsVr0Ts08yd8RBW86-Vj38mp0LNW2CFBVx7fjM6rW5vvhx-1Qz31rW93BT4_1Jwx5MW5z2Hhc37c9-s37sh1) confirm: **It’s a multi-cloud world!**  Ninety-two percent (**92%) of enterprises embrace a multi- or hybrid-cloud strategy and 36 percent spend more than $12 million per year on public clouds**. Cloud plans and adoption have clearly shifted as a result of the pandemic and cloud usage is higher than was initially planned. We’ve seen these stats reflected in our customers’ increasing demand for multi-cloud support over the past few months. **Maintaining independence from any single public cloud vendor, mitigating the risk of outages in entire regions or avoiding cloud vendor lock-in are just some of the advantages for this migration.** However, multi-cloud strategies go hand in hand with a complex architecture, which is more challenging to manage. That’s why **multi-cloud tooling is essential for managing cloud resources successfully and cost-effectively, while ensuring strong governance and security.** At Kubermatic, we believe that multi-cloud is the future, and **managing services across the multi-cloud infrastructure should be simple**. It's why we're constantly working on solutions to manage services more easily on multi-cloud. Are you embarking on your cloud adoption journey but feeling a bit overwhelmed? Join our ***Ask Us Anything About Multi-Cloud* Session on June 16 at 5:00 PM CEST** and I’ll be happy to share our experience and learnings, to help you succeed in this endeavour. ## PRODUCT UPDATES ![Writing on tablet](/static/pexels-kaboompics-com-6336.jpeg) ## Kubermatic Kubernetes Platform 2.17 Is Out! The big story for this recently announced release is our collaboration with our **long-standing client-partner SysEleven**, resulting in the **new etcd backup and restore controllers** that make every operator’s life a whole lot easier. The latest KKP release also comes with **Multus CNI support, and a fully-fledged UI integration of the Open Policy Agent (OPA)**. **[Find Out More](https://www.kubermatic.com/blog/just-released-kubermatic-kubernetes-platform-2-17/?utm_medium=email&_hsmi=2&_hsenc=p2ANqtz--uFeHvKKWtgIPuD1dErX3_6_ad0H0r1nN4suGRZvbzcCwqqkR_CZsyBm0Tp07PqsmX0E5QA7MDt3qi158KTg_HD367HA&utm_content=2&utm_source=hs_email)** ## KUBERMATIC BLOG ![Blog blocks](/static/pexels-miguel-a-padrinan-1591056.jpeg) * [How to Manage Multi-Cluster Kubernetes with Operators](https://it.t.hubspotemail.net/e2t/tc/VXcF9D8PRXRzW1b8Jr54HTZ0YW6L2xF54r_HNQN4jRWcQ3lGnpV1-WJV7CgLBVW9bCTBP7m-rZcN4D6FDn9g8RKW232FLj33dt5QW1jjvF41hf4jyW4HqyzS8LZVF7W3cdkRF5SLVXGW5dzprM47mtW8W72My3914hqt0W7r_VWS275RRXW7rVMG27n6qR-Vy3MSp4fkD1-W53hFL_3pbD24W1mrljl7KHY9GN5SBlNgJDF6pW5Str4n7KdyF3W4rVNM05KxZ41W5TlqD91Z_7BxW3HpNbV5lXcJBW4kf0C-4JW2JvW7zhdGx2hCnpdW793X7J4pNN3VW2wSYG67X4_5vW3FLDq17n6l-9W8KKk8z6tb3y8W8Wg93T1hWmp_W6VpS854GCy_k3cbl1) * [Combating Kube Chaos Without Losing Your Sanity](https://it.t.hubspotemail.net/e2t/tc/VXcF9D8PRXRzW1b8Jr54HTZ0YW6L2xF54r_HNQN4jRWcw3lGn5V1-WJV7CgJz0W13lwb56Wj3zCW4RQTcr8NtvjBW3rDXBg3k0LjBW7rN5y26crqf-VX86J08HSYFRW4R_ZmZ6fXfygW93jf-79681DGW7JRYvh4xYBBqVYTgs17yZ30yN7SZh26vrwHdW4xyzX219BbC4VHlHlf48TJGzW3NygJv98QhJ9W7cmSD52f1d15W7vcnbg4_Sbk3W9fgLmd8qXjmRW5mBt8v959sHHW71cnKn4XV5-hW5c86Bs8jWPNmW5pVD_v31G0b8N7hVZ0GmCLtMW9lgKml3Zz0WzW3zZFmm53Nt0rW2V6NG_1pyk-T3gxm1) * [Getting Started With KubeCarrier](https://it.t.hubspotemail.net/e2t/tc/VXcF9D8PRXRzW1b8Jr54HTZ0YW6L2xF54r_HNQN4jRWcc3lGmQV1-WJV7CgMHgW22BNcR4hdMb9W5wXFbx7nCn1fW72hwxQ51lvxnW7XzK6T7nb7LlMHL45V9jFGkW7019BP1Wz4zLW6lX3Cp76Z3GLW8djnGs5rWhZZW12p-G02JN4VTW1Ksyhc3T4f_GVVxF005DDlS0W2yVBSW2lmbfhW5SzRB_1j7pbWW8dV7KY7TF6HTVqfn_42tnB2mW1_hkKG915xqSW8CTkk24Xz4TYW5NQwjh4byZVcW3JWlvw8V3m50N3C2PvBfcdP7N4LNHBRbJC71W6pVMXc9cbR1d3p_J1) **[Discover Our Blog](https://www.kubermatic.com/blog/?utm_medium=email&_hsmi=2&_hsenc=p2ANqtz-9GuH3D-8leH8E17wBrQsfzP9hqG3vORRK0fpqDcJ0p1vOuuKSpkg-9Xwr-bdQDkP1zPtuysYkb7Fv32hmOHgRYiVnMSw&utm_content=2&utm_source=hs_email)** ## KUBERMATIC RESOURCES ![Girl hiding her face with a book](/static/siora-photography-hgfy1mzy-y0-unsplash.jpeg) **\#1 Demo** Automate operations of hundreds of Kubernetes clusters across any hybrid or multi-cloud environment. KKP provides you with standardized cluster installations, centralized compliance, full life cycle management and business critical support. [Automate Your Clusters Across Multi-Cloud with KKP](https://it.t.hubspotemail.net/e2t/tc/VXcF9D8PRXRzW1b8Jr54HTZ0YW6L2xF54r_HNQN4jRWcQ3lGnpV1-WJV7CgXhjW462SJb7-pFKqN2j9tY9p040XW3jmPsh5Q7RNBW9lnSfY8vpHP6W5f0S1761Q2CyW3Jwy97422G0dW2H08778b5gLFW5N-bmP1r-m3dW3QcD9d1lj8q_W1dNCNG2T1MPrVr5QnT8SZF6BN49GrmC38VV5N1RtNYCyvnZrW6xbD651clZH_W7kxcS31K0sHDW7FTXm25Lf3cBW6pb8z11LpRN7W3kh5l-3MhW-JW8nWRjy26vgK4W7J4_z26g1gtbW8kXjjZ7zRbBQW7697yr36MhSPW7CrN5b54vNczW4pTgCz2SkZLVW2d-v7r1QvwbtW2pJXj97N_fQn3gSw1) **\#2 Video** As the number of clusters increases, the management of these clusters and the applications running in them quickly becomes the operators’ final boss. In this demo, we show you how to conquer this challenge with KKP and KubeCarrier. [Fighting the Final Boss: Complex Multi-site Multi-cluster App Deployments](https://it.t.hubspotemail.net/e2t/tc/VXcF9D8PRXRzW1b8Jr54HTZ0YW6L2xF54r_HNQN4jRWcw3lGn5V1-WJV7CgSGfW6Bhbsv9lqZH6W2MJ7Wx6_TwhTTFBvq6KPRKwW2Tpx8z86YjPyW1Qlv4Z62RHvKW8Hgftn5RdhmGW2ztkg81nsm2MW4cFmbM43HNmlW4fD0WW8FLP7YW12P-Dv8SZBHYW92cBLR8JwSP9W7krpLk8-ChbzW1NFHcC18xHJxW4M43PW1g2p47W3BQjGr2kJvnhW1fHNBm2n8n2ZW2lLHxQ6VKQQ6W8kx9jK5V--hHN1t-YzbJkvdJW3wJ2F961m_JQW6wr_sr3L457qW6rtS0f2NZrXZW3y0Smy5WfnFhW34sXYx1tsQWq3cnx1) **\#3 KubeCon Talk** Complex application services consisting of multiple interconnected components can benefit from deployment in multiple Kubernetes clusters. However, this approach has some/a lot of challenges. In this video, you’ll see what this type of deployment looks like, with the help of KubeCarrier. [How to Deploy Multi-cluster Services With Operators and KubeCarrier?](https://it.t.hubspotemail.net/e2t/tc/VXcF9D8PRXRzW1b8Jr54HTZ0YW6L2xF54r_HNQN4jRWbD3lGmcV1-WJV7CgFwtN6Bs35stWCq3W4b9J7S2HHW93N17qLrJMVM8dW8nd0p98H5mg3W3yL3dG5S8B_QW3TBycQ95l04cN31b5yxQZXXpW9d5dJK2gwtrlW3tdkcw84Trz-W1LcwLG7FVbThW5WPrZ04s-_r6W47tpt-7VbLkfW2b4g1j2nHQtWW8J2CWT32t1DQW27YXyf8yl045W7QnF7J10slf3VmGLw31GqCT_W5LcC077SQyz33hH01) **[Browse Our Resource Library](https://www.kubermatic.com/resources/?utm_medium=email&_hsmi=2&_hsenc=p2ANqtz--BzYdcGdTYfZDA87QRMBYfk6ChXRBmf7vX7nOhgR6Wo21X29FfbXPSgiBDOLCS99tZFXEdRKcdra09XlanfoFgPWRXFw&utm_content=2&utm_source=hs_email)** ## **PARTNER COMMUNITY** ![People holds the hands](/static/pexels-fauxels-3184418.jpeg) ## Announcing SVA as a New Reseller Partner New partner on board! [System Vertrieb Alexander GmbH (SVA)](https://it.t.hubspotemail.net/e2t/tc/VXcF9D8PRXRzW1b8Jr54HTZ0YW6L2xF54r_HNQN4jRWbD3lGmcV1-WJV7CgB7YW5TFw5y8MVfvxVMVCjN4JRM5WW86R4276ztwGtW6BW9wT19F9C7W46gp066wrHyjW8tHtK225L_CFW4Lbpsm6_tTkJN35ZDrfQkcjCW5PT6tn1nmb4vN1h7Tk1Qd42bW7Dvf406_HFRbW60GdBY3lKYswW6k1DXW7FGvnKW36xblC3LPk1HW1FtmDZ4QtRsDW9bh22_8y-1RCW8lkX4K6Xp2ytW23fTcp9dnVcc3nQn1), one of Germany’s leading systems integrators for high quality IT products is now an official reseller partner. SVA’s reputation for excellent customer service and IT agility, combined with our well established Kubernetes automation portfolio, will provide customers with optimum solutions for their cloud native deployments at scale. **[Read the Blog](https://www.kubermatic.com/blog/announcing-sva-as-a-new-reseller-partner/?utm_medium=email&_hsmi=2&_hsenc=p2ANqtz-8diULRq3hwOr_eifOd2SNjW6Q7fmKI1DphcCNyMAIEtNxGiB6rDQ7tPE-iI0Bsf4vkiE3Po5iyV8teIn2oFEGZrmv24Q&utm_content=2&utm_source=hs_email)** **[Become a Partner](https://www.kubermatic.com/partners/?utm_medium=email&_hsmi=2&_hsenc=p2ANqtz-_9ds5GbNL-B7c_Ik5vNuOBYDJSmW-xDp0qENx1zH3Eepxbpwwe0hED09--2YKgUgowKmduTzFb-YXtzbjkf9a3Q53lkg&utm_content=2&utm_source=hs_email#partner-form)** ## UPCOMING EVENTS ![Calendar on a tablet screen](/static/pexels-pixabay-39578.jpeg) ## ContainerDays Hybrid 2021 Whether you're just starting your cloud adoption journey or already have your initial projects up and running, [ContainerDays](https://it.t.hubspotemail.net/e2t/tc/VXcF9D8PRXRzW1b8Jr54HTZ0YW6L2xF54r_HNQN4jRWcw7hMntV5X_Kf7CgWxFW5p4RZz5RVRffVhjRRs99KnB8W79trbp5dG4zQW3K8W9H25HLZyW4QKf9b4gmKtPW3JPsk38Xq-3CW3ySMJN2YZZS0N1PrtTrMl-8qW8Rg0f_19mwrSW4t1yXj3S3CgkW572DJX7f0lyWW1FvVws84HzxHW7K3v657-kdD2VfzsLX4zQyPyW93Nft99fD3GHVC1skb7bRm99W20r-HJ8LVsstVNQfNG1f705QW2nSBGm89JSm1W4f0srJ7mztHBW35SbXC6b7n-kW5fvZQp5QR_4xW66BnTD918m2DW4jzsnh7SSLkdW7FpSH_5DnH4hV3gDMV4QVWztN5FFB4lxwyZrW8S_KQS7Ym5MGW7Xj9Pt1j2dZzW2yb_cd5pqhw-V669Dl2CpQpXV5WFvw2x5ggNW2cpDvz6pHQxFN10XhyWDr30sW7D6kxP2S9_kLW44SLCP1Kk41mW6DB2kJ28JQ7bW3xdKx745w7qsW3nlyp643HjJLW2rgqXr18fygpW8P9sdL8mWwNvW45jbHC8YzdbXVGf9z14FBHC3W7Nb_Cg3xc1TMW4T2d3530GYvmW3Nm2Zh4KXQfpW7gkFDs2_5rthW6F-jJ48nTH2vW18nvbw7hV3QDM7gVzTbMHXSV8_Fbb6D-bTRW9d5yPQ84QcmfW6jfNQR29Dr35W6vnWYw50rZG-W3ggJJx2XFhHlW26WHLm1_XT2r3mcL1) is the place to be to collaborate with other cloud native enthusiasts from around the world. Join us from **September 21-23** virtually or in the beautiful city of Hamburg. **[Get Your Early Bird Ticket](https://www.containerdays.io/tickets/?utm_medium=email&_hsmi=2&_hsenc=p2ANqtz-_FUXZVcGy14lhu7n59cgOiNXQDAYSkKW33ISsHcD6SQM9QGac5wV1c4BlC5zrVaYo_ROZ9SuNrjk3ESNV5xNBJc8qZng&utm_content=2&utm_source=hs_email)** **[Submit Your Talk ](https://sessionize.com/containerdays-2021/?utm_medium=email&_hsmi=2&_hsenc=p2ANqtz-_9Td4illjKYUVlFofk7HaIb-8jdP_IG6lNN_I455_Awnka3hpnnBBmjihQOSXHl9zZQLJLs7uhtwmbhpqRU8wAVGdpkQ&utm_content=2&utm_source=hs_email)** For a more comprehensive look into the world of Kubernetes and cloud adoption, check out our **upcoming webinars** and pick the one that’s right for you. **[Visit Our Event Page](https://www.kubermatic.com/events/?utm_medium=email&_hsmi=2&_hsenc=p2ANqtz-_J4Fw_WvT_5_gYWtD0oE8WkOGkgxZt7Tud9BJ16rAVlKVCIFK-6h1kwg9YpDl8JRy_dYt89LAInOnWXaYmhg9ExfGHyA&utm_content=2&utm_source=hs_email)** See you soon! Cheers. *P.S.: We're hiring! Are you a Kubermaniac just like us? Check out our [job openings](https://careers.smartrecruiters.com/KubermaticGmbH?utm_medium=email&_hsmi=2&_hsenc=p2ANqtz--bXyJsyGua09A8x7kLkkX_U1wDHmSdg7jMrBrF-tBXyPH8Z2OWTpsOwfFLhve5se0DVhh7dHVPChAdEy3tVAimBAaP9Q&utm_content=2&utm_source=hs_email).* --- ## Kubernetes ReplicaSet: An Introduction - **URL:** https://www.kubermatic.com/blog/introduction-to-kubernetes-replicasets/ - **Date:** 2026-05-07 - **Description:** A ReplicaSet makes Kubernetes application management easier by running multiple instances of a Pod and keeping the specified number of Pods constant. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Seyi Ewegbemi In this part of our series, we are focusing on Kubernetes ReplicaSet. Just like the previous parts, there will be hand-on practice to allow you to get acquainted with the features and functionalities of a ReplicaSet which include using ReplicaSet to scale applications up or down. This Kubernetes object makes Kubernetes application management easier. ## **Kubernetes ReplicaSet** A ReplicaSet is a process that runs multiple instances of a Pod and keeps the specified number of Pods constant. Its purpose is to maintain the specified number of Pod instances running in a cluster at any given time to prevent users from losing access to their application when a Pod fails or is inaccessible.   ReplicaSet helps bring up a new instance of a Pod when the existing one fails, scale it up when the running instances are not up to the specified number, and scale down or delete Pods if another instance with the same label is created. A ReplicaSet ensures that a specified number of Pod replicas are running continuously and helps with load-balancing in case of an increase in resource usage. ## **Creating a Kubernetes ReplicaSet** We will create an example ReplicaSet using the below configuration, just like we created a Pod in [part 3](https://www.kubermatic.com/blog/introduction-to-pods/?utm_content=136078152&utm_medium=social&utm_source=twitter&hss_channel=tw-3614488228) of this series.  Before we begin, you should already have a running Kubernetes cluster and configured the kubectl command-line tool to communicate with the cluster. If you need guidance, you can find detailed instructions on getting a cluster running using KubeOne in [this setup guide](https://github.com/kubermatic/kubeone#getting-started). Basic knowledge of Pod is suggested to follow the exercise. **Step 1:** Create a YAML file using vim on the command line: ```bash $vim replicaset-app.yaml ``` **Step 2:** Copy, paste, and save the configuration below into your YAML file. The indentation is crucial! ```yaml apiVersion: apps/v1 kind: ReplicaSet metadata: name: my-replicaset spec: replicas: 2 selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: containers: - name: my-container image: nginx ```  **Step 3**: Create the ReplicaSet with this command: ```bash $kubectl create -f replicaset-app.yaml replicaset.apps/my-replicaset created ``` **Step 4:** Once the ReplicatSet is running, you can check its status: ```bash $kubectl get replicaset my-replicaset NAME DESIRED CURRENT READY AGE my-replicaset 2 2 2 17s Name: ## This is the name of the ReplicaSet declared as the child of the metadata property Desired: ## This is the replica number specified in the YAML manifest file Current: ## This equates to the current state of the ReplicaSet; that two replicas are up Ready: ## The two replicas specified are ready and in the running state Age: ## How long the replicas have been in the running state ``` **Step 5:** Next, you can check the status of the Pods running in the ReplicaSet: ```bash $ kubectl get Pods NAME READY STATUS RESTARTS AGE my-replicaset-ccjfj 1/1 Running 0 5m18s my-replicaset-m4bb7 1/1 Running 0 5m18s ``` ## **Scaling Your Application:** An application can either be scaled up or down depending on the situation in two ways. Using the first method, you can edit the configuration file we created earlier in this exercise by changing the `replicas` property value to a higher number to scale up or a lower number to scale down.To scale up, edit the manifest file and change the `replicas` value from 2 to 5. Save and exit the vim terminal and then run the below command. ```bash $ kubectl replace -f replicaset-app.yaml replicaset.apps/my-replicaset replaced ``` To get the status: ```bash $ kubectl get replicaset my-replicaset NAME DESIRED CURRENT READY AGE my-replicaset 5 5 5 12m ``` Next, you can check the status of the Pods running in the ReplicaSet: ```bash $ kubectl get Pods NAME READY STATUS RESTARTS AGE my-replicaset-bq9wz 1/1 Running 0 15m my-replicaset-c5h4x 1/1 Running 0 3m43s my-replicaset-hj59z 1/1 Running 0 3m43s my-replicaset-hpvxr 1/1 Running 0 15m my-replicaset-xgwfx 1/1 Running 0 3m43s ``` As seen in the ReplicaSet and Pod statuses, there are 5 Replicas running and ready for use, as well as 5 Pods. To scale down, change the value of the `replicas` in the manifest file from 5 to 1, then run the command below again. ```bash $ kubectl replace -f replicaset-app.yaml replicaset.apps/my-replicaset replaced ``` Check the status of the ReplicaSet: ```bash $ kubectl get replicaset my-replicaset NAME DESIRED CURRENT READY AGE my-replicaset 1 1 1 4m9s ``` Check the status of the Pod: ```bash $ Kubectl get Pods NAME READY STATUS RESTARTS AGE my-replicaset-89dkw 1/1 Running 0 4m15s ``` You can see that the number of Replica and the running instance of a Pod are the same as the number specified in the manifest file `replicas` field. An application can also be scaled up or down using the command line which is the second method. ```bash $kubectl scale - -replicas=5 -f replicaset-app.yaml ## Scale up $kubectl scale - -replicas=1 -f replicaset-app.yaml ## Scale down ``` Or ```bash $kubectl scale - -replicas= 5 replicaset <replicaset name> ## Scale up $kubectl scale - -replicas= 1 replicaset <replicaset name> ## Scale down ``` ## **Summary** This guide has introduced you to how Kubernetes ReplicaSet can automate application lifecycle management for efficiency. Next in our series, we will look at Kubernetes Deployment, and its functionalities. We encourage you to [contact us](mailto:marketing@kubermatic.com) with any questions you have.     ## **Learn More** * Read more on [Kubernetes ReplicaSet](https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/) on the Kubernetes official website * Get more insight into the [Kubernetes ReplicaSet here](https://kubernetes.io/docs/tutorials/kubernetes-basics/update/update-intro/) --- ## How to Write Software to Set Up Kubernetes Anywhere - **URL:** https://www.kubermatic.com/blog/how-to-write-software-to-set-up-kubernetes-anywhere/ - **Date:** 2026-05-07 - **Description:** Learn more about KubeOne, a Kubernetes cluster lifecycle management tool - **Categories:** Community, Best Practices - **Tags:** Kubernetes, Open Source Projects - **Authors:** Marko Mudrinić Although Kubernetes is a very complex system, installing it doesn’t have to be hard if you use existing tooling. In this blog post, I want to share what we learned while creating KubeOne, a Kubernetes cluster lifecycle management tool. Let’s start with a 10,00 feet view on how a cluster lifecycling management should look like: ![Kubernetes cluster lifecycle management tool](/static/creating-new-kubernetes-cluster.png) We have a user-provided manifest that defines what our cluster should look like. The manifest is given to the tool, which creates a new cluster, based on that manifest. This allows us to implement a declarative approach, which is widely used in the Kubernetes ecosystem and has a lot of advantages. **So, what should our tool do?** The Kubernetes community is very large and has created a lot of tools to make managing clusters easier. We all know from experience that it’s always better to reuse as many tools as possible, so you don’t have to implement everything from scratch.  To answer the question, let’s have a look at Kubeadm, the official Kubernetes cluster management tool that creates production-ready, conformant clusters right out of the box. Kubeadm does **everything** Kubernetes: * It provisions the control plane and the worker nodes * It can upgrade the cluster * It can manage configuration and certificates And so much more. The best part is that it works **anywhere**, including cloud, on-prem and bare metal. However, the Kubeadm’s philosophy only takes care of Kubernetes and Kubernetes cluster management. It’s supposed to be used as a **building block** in other tools and scripts.  **So what about everything non-Kubernetes, like:** * Infrastructure and provisioning instances * Configuring instances * Installing packages like Container Runtime, Kubeadm or Kubelet * Running Kubeadm itself  * Installing addons like CNI or metrics-server For configuring instances, installing packages and running Kubeadm, we can use well-established tools and protocols like cloud-init or SSH. For installing addons, we can use Kubectl, client-go, Helm…or whatever else works best for you. **Infrastructure and provisioning instances are a little more challenging.** There are so many providers and setups, like cloud with AWS, GCP and so on; on-prem with vSphere and OpenStack, bare-metal, edge and the like. Every provider has different features, structures and APIs, with endless possibilities in terms of architecture, making the challenge even greater.  Let’s look at three (3) ways of handling the infrastructure problem: 1. Implement the infrastructure management tool. 2. Use an external infrastructure management tool (e.g., Terraform). 3. Use a combination of the previous two, i.e. the hybrid approach. Managing the infrastructure ourselves assumes that the manifest includes the information about how the infrastructure should be created, as well as information about the Kubernetes cluster. The tool creates the infrastructure and instances, and then installs and provisions Kubernetes on those instances. The problem here is that we lose the ability to create clusters anywhere. If our tools don’t support a certain provider or architecture, the user will not be able to use it.  However, we can easily address this by using an external infrastructure management tool, like Terraform, to create the infrastructure and instances, and provide the information about those instances, as well as how to access them, to our tool. The user-provided manifest will contain information specific to the desired Kubernetes cluster. Then the tool can use SSH to access these instances and install Kubernetes there. ![External infrastructure management](/static/image1.png) **The hybrid approach, which is also used by KubeOne, is the best option, because it offers a lot of flexibility.** The external tool is used to create the infrastructure and control plane instances. Then our tool provisions and manages the Kubernetes control plane. Lastly, we implement the Cluster API-based Kubernetes controller, used for managing worker nodes. This allows us to manage our worker nodes using the Kubernetes API and use features like auto-scaling and so more… ## Where to Learn More * KubeOne Demo: [Deploy and Manage Your Cluster Everywhere With KubeOne](https://www.kubermatic.com/resources/demo-deploy-and-manage-your-cluster-everywhere-with-kubeone/) * Documentation: [What Is KubeOne?](https://docs.kubermatic.com/kubeone/v1.2/) * Find [KubeOne on Github](https://github.com/kubermatic/kubeone) --- ## Live Office Hours May 2021 - **URL:** https://www.kubermatic.com/resources/live-office-hours-may-2021/ - **Date:** 2022-12-01 - **Description:** Learn more about how to use our open source products Kubermatic Kubernetes Platform and Kubermatic KubeOne. # Office Hours ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Our May Office Hours Watch our Live Office Hours session and learn from the Kubermatic technical experts. You’ll get product deep-dives and interesting insights of the Q&A sessions that equip you with everything you need to use our open source products Kubermatic Kubernetes Platform and Kubermatic KubeOne. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Kubernetes ConfigMaps: An Introduction - **URL:** https://www.kubermatic.com/blog/keeping-the-state-of-apps-part-3-introduction-to-configmaps/ - **Date:** 2026-05-07 - **Description:** Learn more about Kubernetes resources and their usage. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Seyi Ewegbemi In the last part of this series, we focused on Secrets which is one of the Kubernetes objects that deals with keeping your data safe and secured. In this part, we will look at ConfigMaps which is a similar Kubernetes object but differs in use case to Kubernetes Secret. After digging into theory, we will follow up with hands-on practice to test the use case and functionalities of a ConfigMap in Kubernetes. ## **What is a ConfigMap?** A ConfigMap is a Kubernetes object used to store non-sensitive data in contrast to a Secret which is used to store sensitive data. A ConfigMap can be injected into a container in a Pod as environment variables at runtime, as a command arg, or as a file via volumes and volumeMounts. It uses a **data** property in the manifest YAML file to store configuration data as key-value pairs in lieu of **spec** as applicable to other Kubernetes objects. ## **Creating a ConfigMap** You can create a ConfigMap in two ways, which can be either declarative or imperative. You can read more on the [imperative and declarative ways of creating Kubernetes objects](https://www.kubermatic.com/blog/kubernetes-as-a-container-orchestration-tool/) in part two of this series. ## **Imperative Method** Creating a ConfigMap in an **imperative way** is possible in three ways. You can create it from **files**, **directories** or **literal** **values**.  Before we begin, it is imperative that you have basic knowledge of Pod, Deployment and volumes to follow this exercise. You also need a running Kubernetes cluster, and a kubectl command-line tool must be configured to communicate with the cluster. You can easily create a Kubernetes cluster on any environment with [KubeOne](https://github.com/kubermatic/kubeone#getting-started). Check our [Getting Started](https://github.com/kubermatic/kubeone#getting-started) for instructions. Alternatively, you can use the [Kubernetes playground](https://labs.play-with-k8s.com/) for practising purposes. ## **Create a ConfigMap from Files** You can create a ConfigMap from single or multiple files using `$ kubectl create configmap (name of the map) (file-name)`. ## Create a ConfigMap from Single File The below steps will guide you on how to create a ConfigMap and check the status and description.\ \ **Step 1:** Create a file to store your data. ```bash $ vim config1-example.txt ``` **Step 2:** Store the below data into your file, save, and exit the terminal. You can save any data of your choice into the file created above. ```text City: Hamburg State: Hamburg Country: Germany ``` **Step 3:** Run the command below to create the ConfigMap. ```bash $ kubectl create configmap config-example1 --from-file=config1-example.txt configmap/config-example1 created ``` **Step 4:** Check the status of the ConfigMap. ```bash $ kubectl get configmap config-example1 NAME              DATA     AGE config-example1       1          4m8s ``` **Step 5:** Check the ConfigMap description. ```bash $ kubectl describe configmap config-example1 Name: config-example1 Namespace: default Labels: <none> Annotations: <none> Data ==== config-example.txt: ---- City: Hamburg State: Hamburg Country: Germany Events: <none> ``` ## **Create a ConfigMap from Multiple Files** You can pass the `--from-file` flag several times to create a ConfigMap from multiple filenames or data sources. The steps below will guide you through the exercise. **Step 1:** Create another file in addition to the one created above. ```bash $ vim config2-example.txt ``` **Step 2:** Store the below data into your new file, save, and exit the terminal. You can save any data of your choice into the file. ```text City: Ann Arbor State: Michigan Country: USA ``` **Step 3:** Run the command below to create the ConfigMap from the two files that you created above. ```bash $ kubectl create configmap config-example2 --from-file=config1-example.txt --from-file=\ config2-example.txt configmap/config-example2 created ``` **Step 4:** Check the status of the ConfigMap. ```yaml $kubectl get configmap config-example2 NAME DATA AGE config-example2 2 10s Name → ## The name of the ConfigMap Data → ## The number of data in the ConfigMap Age → ## The ConfigMap running time ``` **Step 5:** Check the ConfigMap description. ```bash $ kubectl describe configmap config-example2 Name: config-example2 Namespace: default Labels: <none> Annotations: <none> ``` ```text Data ==== config1-example.txt: ---- City: Hamburg State: Hamburg Country: Germany config2-example.txt: ---- City: Ann Arbor State: Michigan Country: USA Events: <none> ``` You can see in the description above the data stored in both files under the data field. ## **Create a ConfigMap from Directories** You can create a ConfigMap from a directory by storing multiple files in the directory and then using `$ kubectl create` to create a ConfigMap from the multiple files saved in the directory.  In this method, kubectl identifies the files with the valid key names in the directory and packages them into the ConfigMap. ## **How to Create a ConfigMap from Directories** You can create a ConfigMap from a directory using `$ kubectl create configmap (name of the configmap) (directory name/path)`. The below steps will guide you through. **Step 1:** Create a directory. ```bash $ mkdir -p configmap/directory ``` **Step 2:** Change into the directory and create a file. ```bash $ cd configmap/directory $ vim config-dir1 ``` **Step 3:** Copy, paste, and save the data from the first exercise into your file and exit the terminal. **Step 4:** Create another file. ```bash $ vim config-dir2 ``` Copy, paste, and save the data from the second exercise into your file and exit the terminal. **Step 5:** Check the directory to be sure that the files are created using `ls` command. ```bash $ ls config-dir1  config-dir2 ``` Change back to the home directory using `cd` and then enter key. **Step 6:** Run the command below to create a ConfigMap from the directory. ```bash $ kubectl create configmap config-example --from-file=configmap/directory configmap/config-example created ``` Check the status of the ConfigMap: ```bash $ kubectl get configmap config-example NAME DATA AGE config-example 2 31s ``` Check the description: ```bash $ kubectl describe configmap config-example Name: config-example Namespace: default Labels: <none> Annotations: <none> ``` ```text Data ==== config-dir1: ---- City: Hamburg State: Hamburg Country: Germany config-dir2: ---- City: Ann Arbor State: Michigan Country: USA Events: <none> ``` The description and the status above produced the same output as that of creating a ConfigMap with multiple files. ## **Creating a ConfigMap from Literal Values** You can create a ConfigMap from literal values by using `--from-literal` tag on the command line. It uses a key-value pair or multiple key-value pairs to create the ConfigMap. ## **How to Create a ConfigMap from Literal Values** Run the command below to create the ConfigMap: ```bash $ kubectl create configmap literal-example --from-literal=City=Hamburg --from-literal=Country=Germany --from-literal=username=Ann-Arbor --fromliteral=Position=Director --from-literal=Department=Admin configmap/literal-example created ``` Check the ConfigMap status: ```bash $ kubectl get configmap literal-example NAME DATA AGE literal-example 6 26s ``` Check the detailed status in a YAML format: ```yaml $ kubectl get configmap -o yaml apiVersion: v1 items: apiVersion: v1 data: City: Hamburg Country: Germany Department: Admin Position: Director State: Hamburg username: Ann-Arbor kind: ConfigMap metadata: creationTimestamp: "2020-08-13T15:46:42Z" managedFields: apiVersion: v1 fieldsType: FieldsV1 ``` Check the description: ```bash $ kubectl describe configmap literal-example Name: literal-example Namespace: default Labels: <none> Annotations: <none> ``` ```text Data ==== username: ---- Ann-Arbor City: ---- Hamburg Country: ---- Germany Department: ---- Admin Position: ---- Director State: ---- Hamburg Events: <none> ``` **Note:** In literal values, you can not use a key for two different data, unlike the other methods we used earlier. ## **Declarative Method** You can create a ConfigMap in a declarative way by first declaring the configuration data in a manifest YAML file and then use **kubectl create** command to create the ConfigMap.  Follow the below steps to create a ConfigMap using the declarative method. **Step 1:** Create a file with YAML syntax extension. ```yaml $ vim config-declarative.yaml ``` **Step 2:** Copy and paste the below configuration into the file, save and exit the terminal. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: manifest-example data: city: Ann Arbor state: Michigan apiVersion → ## This field represents the version of the ConfigMap API. kind → ## The object kind which must be the name of the object metadata.name → ## The name of the application configuration which can be any value Data → ## This field holds the data of the ConfigMap, which consists of the keys and the values. ``` **Step 3:** Create the ConfigMap using the below command. ```bash $kubectl create -f config-declarative.yaml configmap/manifest-example created ``` Check the status and description using the commands used in the previous exercises. ## **Application Configuration using ConfigMap** You can use ConfigMap to configure your application by using **files** in read-only volume or as **Environment variables**. We will walk you through the use of both methods and perform some exercises. ## **How to Configure an Application using Files** The following steps will guide you on how to configure your app using files. You need to first create a ConfigMap before creating the Pod and then reference the ConfigMap in the Pod by adding a volume. Then, mount the volume with volumeMounts property in the Pod manifest file.  A running Kubernetes cluster and a kubectl command-line are essential for this exercise, just like the previous exercises. The kubectl command-line tool must be configured to talk to the cluster. Details on how you can get a cluster running using [KubeOne](https://github.com/kubermatic/kubeone#getting-started) can be found [here](https://github.com/kubermatic/kubeone#getting-started). Follow the steps below to configure an application using files: **Step 1:** Create a ConfigMap. ```bash $ vim config-file.yaml ``` **Step 2:** Copy, paste and save the below manifest in your YAML file and exit the terminal. ```yaml apiVersion: v1 kind: ConfigMap metadata: namespace: default name: my-configmap data: app-config: City = Hamburg State = Hamburg Country = Germany ``` **Step 3:** Create the ConfigMap using `kubectl create`. ```yaml $ kubectl create -f config-file.yaml configmap/my-configmap created ``` **Step 4:** Check the ConfigMap status. ```bash $kubectl get configmap config-example1 NAME DATA AGE config-example1 1 4m8s ``` **Step 5:** Create the Pod that will consume the ConfigMap. ```yaml $ vim pod-file.yaml ``` Copy, paste, and save the below manifest into your file and exit the terminal. ```yaml apiVersion: v1 kind: Pod metadata: namespace: default name: myapp labels: app: my-app spec: containers: name: my-app image: nginx ports: containerPort: 8080 imagePullPolicy: Always volumeMounts: name: my-volume mountPath: /app/config volumes: name: my-volume configMap: name: my-configmap volumes.name → ## The name of the volume is declared in this field volumes.configMap → ## The ConfigMap is declared in this field volumes.configMap.name → ## The name of the ConfigMap which must be the same with the name of ConfigMAp created earlier volumeMounts.name → ## The declared volume is injected into the Pod in this field which is why the declaration is under the container specification; the name must be the same as the name of the volumes volumeMounts.mountPath → ## The unused directory where you will like the ConfigMap to appear ``` **Step 6:** Create the Pod using `kubectl create`. ```bash $ kubectl create -f pod-file.yaml pod/myapp created ``` **Step 7:** Check the Pod status. ```bash $ kubectl get pods myapp NAME READY STATUS RESTARTS AGE myapp 1/1 Running 0 17s ``` Now that the Pod is running, you need to exec into the Pod to confirm if the ConfigMap has been injected. You can read more on exec-ing into a Pod in part two of this series. **Step 8:** Exec into the Pod. ```bash $ kubectl exec -it myapp -- /bin/bash ## where myapp is the name of the Pod root@myapp:/# ``` **Step 9:** Change into the mountPath directory(/app/config) declared in the Pod manifest and check the file in the folder. ```bash $ root@myapp:/# cd /app/config $ root@myapp:/app/config# ls app-config ``` **Step 10:** Open the file using `cat`. ```bash root@myapp:/app/config# cat app-config City = Hamburg State = Hamburg Country = Germany ``` The final output shows that the ConfigMap has been injected into the Pod. This is why you can view the data stored inside the ConfigMap in the container in a Pod. ## **How to Configure Your Application Using Environment Variables** The following steps will guide you on how to configure your app using environment variables. You need to first create a ConfigMap before creating the Pod/Deployment. Then, reference the ConfigMap in the Pod/Deployment by adding the environment variable block which contains properties such as name, valueFrom, and others. **Step 1:** Create a ConfigMap and check the status. ```bash $ vim config-file.yaml ``` **Step 2:** Copy, paste and save the below manifest in your YAML file and exit the terminal. ```yaml apiVersion: v1 kind: ConfigMap metadata: namespace: default name: my-configmap data: City: Hamburg State: Hamburg Country: Germany ``` **Step 3:** Create the ConfigMap using kubectl create. ```yaml $ kubectl create -f config-file.yaml configmap/my-configmap created ``` **Step 4:** Check the ConfigMap status. ```bash $ kubectl get configmap my-configmap NAME DATA AGE my-configmap 3 14m ``` **Step 5:** Create the Pod that will consume the ConfigMap. ```yaml $ vim pod-file.yaml ``` Copy, paste and save the below manifest in your YAML file and exit the terminal. ```yaml apiVersion: v1 kind: Pod metadata: namespace: default name: myapp labels: app: my-app spec: containers: name: my-app image: nginx ports: containerPort: 8080 imagePullPolicy: Always env: name: CONFIG-ENV-CITY valueFrom: configMapKeyRef: name: my-configmap key: City name: CONFIG-ENV-STATE valueFrom: configMapKeyRef: name: my-configmap key: State name: CONFIG-ENV-COUNTRY valueFrom: configMapKeyRef: name: my-configmap key: Country restartPolicy: Never ``` If you look at the above manifest, you will see that the `env` property is introduced in lieu of volumes and volumeMounts, as well as the properties described below. ```yaml env.name → ## The name of the environment variable env.valueFrom → ## This field declares where the values are located which is in the ConfigMap env.valueFrom.configMapKeyRef → ## The ConfigMap is declared here env.valueFrom.configMapKeyRef.name → ## The ConfigMap name where the environment variables will be pulled from; the name must be the same as the name of the ConfigMap. env.valueFrom.configMapKeyRef.key → ## The environment variables to pull from the ConfigMap; the key must be the same with the key stored in the ConfigMap configuration. ``` **Step 6:** Create the Pod using `kubectl create`. ```bash $ kubectl create -f pod-file.yaml pod/myapp created ``` **Step 7:** Check the Pod status. ```bash $ kubectl get pods myapp NAME READY STATUS RESTARTS AGE myapp 1/1 Running 0 50s ``` **Step 8:** Exec into the Pod and check if the ConfigMap data has been injected into the Pod using `kubectl exec`. ```bash $ kubectl exec -it myapp -- /bin/bash root@myapp:/# ``` Now that you are in the container, you can populate the data using the `env` command ```bash root@myapp:/# env CONFIG-ENV-STATE=Hamburg CONFIG-ENV-CITY=Hamburg CONFIG-ENV-COUNTRY=Germany ``` The above data showed that the data is stored in the ConfigMap, which has been injected into the Pod. Next in our series, we will continue with the data persistence by introducing you to more Kubernetes objects used for data preservation. You will learn more about PersistentVolumes (PVs) and PersistentVolumeClaims (PVCs) as well as how to make its process more dynamic using StorageClass. We encourage you to [contact us](mailto:marketing@kubermatic.com) with any questions you have! ## Learn More: * Visit the official [Kubernetes website](https://kubernetes.io/docs/concepts/configuration/configmap/) to learn more about Kubernetes ConfigMaps * Learn more about [Kubernetes ConfigMap practices here](https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html/developer_guide/dev-guide-configmaps) --- ## Multi-cluster Multi App Deployments - **URL:** https://www.kubermatic.com/resources/multi-cluster-multi-app-deployments/ - **Date:** 2022-12-01 - **Description:** Learn more about how to automate the full lifecycle of complex multi-cluster solutions consisting of applications spread across multiple Kubernetes clusters. # Multi-cluster Multi App Deployments ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch this Demo and Learn How to Fight the Final Boss With the rise of Kubernetes’ popularity across various use-cases, including edge computing, IoT, 5G, or AI/ML, single-cluster Kubernetes deployments are increasingly becoming an exception rather than the norm. As the number of clusters increases, the management of these clusters and the applications running in them quickly becomes the operators’ final boss. In this tutorial, we will show you how you can master this challenge with open source platforms developed by Kubermatic: Kubermatic Kubernetes Platform for multi-cluster infrastructure management and KubeCarrier for multi-cluster application deployment and management. #### Sascha Haase, VP Edge at Kubermatic ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Get Started With EKS-Distro in Less Than 5 Minutes - **URL:** https://www.kubermatic.com/resources/demo-get-started-with-eks-distro-in-less-than-5-minutes/ - **Date:** 2022-12-01 - **Description:** Learn how to install EKS Distro on AWS and Amazon Linux 2 with minimal operational effort using Kubermatic KubeOne. # Get Started With EKS-Distro in Less Than 5 Minutes ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch the demo and get started with EKS-Distro Recently, AWS introduced Amazon EKS-Distro, a Kubernetes distribution based on and used by Amazon EKS to create reliable and secure Kubernetes clusters. With EKS-D, you can rely on the same versions of Kubernetes and its dependencies deployed by EKS. Great so far…but how to install EKS-D with minimal operational effort?  Luckily enough, you can use Kubermatic KubeOne to easily set up EKS-D on AWS and Amazon Linux 2. Take three minutes to learn how to: - Provision your infrastructure - Create the KubeOne YAML manifest - Run KubeOne apply and get nodes ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## KubeCon 2021: Multi-Cluster Service Deployments With Operators and KubeCarrier - **URL:** https://www.kubermatic.com/resources/multi-cluster-service-deployments-with-operators-and-kubecarrier/ - **Date:** 2024-09-30 - **Description:** Learn more about how to master the challenges of complex application services with the help of Operators and KubeCarrier. # Multi-Cluster Service Deployments With Operators and KubeCarrier ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch the Recording of Our Talk at KubeCon Europe Virtual 2021 Complex application services consisting of multiple interconnected components can benefit from deployment in multiple Kubernetes clusters: Examples include for instance running the application core at a cloud provider and the database with sensitive data in a on-premises cluster or running computational-intensive tasks in a cluster with specialized hardware resources (e.g. GPUs) at the same time. This approach however brings several challenges. How can we interconnect the clusters so that the applications in different clusters can communicate with each other easily? How to allow for multi-tenancy and easily spin up multiple instances of such services in the same clusters? In this talk, you will learn how such a deployment may look like with the help of Kubernetes operators, the KubeCarrier service hub and the Submariner cross-cluster connectivity provider. #### **Rastislav Szabó, Software Engineer at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## How an Operator Becomes the Hero of the Edge - **URL:** https://www.kubermatic.com/resources/how-an-operator-becomes-the-hero-of-the-edge/ - **Date:** 2022-12-01 - **Description:** In this talk at OperatorCon, you'll learn more about operators for the edge computing age. # How an Operator Becomes the Hero of the Edge ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch the Recording of Our Talk at OperatorCon 2021 With the rise of Kubernetes’ popularity across various use-cases, including edge computing, IoT, 5G, or AI/ML, single-cluster Kubernetes deployments are increasingly becoming an exception rather than the norm. As the number of clusters increases, the management of these clusters and the applications running in them quickly becomes the operators’ final boss. In this video, you’ll learn how you can use our open source Kubermatic Kubernetes Platform to fight the final boss and automate the full lifecycle of complex multi-cluster solutions consisting of applications spread across multiple Kubernetes clusters. **Sascha Haase, VP Edge at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Debug a Kubernetes Operator - **URL:** https://www.kubermatic.com/resources/debug-a-kubernetes-operator/ - **Date:** 2022-12-01 - **Description:** In this OperatorCon talk, you'll learn more about how to work with a failing Kubernetes Operator. # Debug a Kubernetes Operator ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch the Recording of Philipp Krenn's Talk at OperatorCon 2021 The goal of this live debugging session is to better understand how to work with a failing Kubernetes Operator and get used to some helpful Kubernetes commands. **Each of the examples follows the same structure:** - Apply an invalid YAML manifest - Figure out what is wrong and how to fix it - Hints that may help solve the problem - A detailed walkthrough to understand and solve the problem #### Philipp Krenn, Developer Advocate & EMEA Team Lead at Elastic ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Instana Distribution to Customer Maintained K8s Clusters - **URL:** https://www.kubermatic.com/resources/distributing-instana-to-customer-maintained-kubernetes-clusters/ - **Date:** 2024-03-21 - **Description:** In this OperatorCon talk, you'll learn more about how to develop and test a complex Kubernetes operator. # Distributing Instana to Customer Maintained Kubernetes Clusters ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch the Recording of Jochen Mader's Talk at OperatorCon 2021 The experience of migrating Instana to Nomad, managing tons of updates and transfering petabytes of data Instana felt comfortable enough to start thinking about shipping Instana int Kubernetes clusters hosted by customers. Within the last year, Instana developed an operator based distribution for some of their biggest customers. By now, they have reached a stable release cycle and are working on new features. In this talk, you’ll learn more about the ups and downs Instana went through when implementing the operator. **Topics covered:** - Why they picked Operators and what the other options were - How to orchestrate 30 different components and 5 different databases - Support air-gapped customers - Automatic updates - Testing such a complex operator using Unit/Integration/Test-pipelines #### Jochen Mader, Principal Systems Engineer at Instana ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Kubernetes Metrics – The Complete Guide - **URL:** https://www.kubermatic.com/blog/the-complete-guide-to-kubernetes-metrics/ - **Date:** 2026-05-07 - **Description:** Deployments of Kuberenetes in production are notoriously massive in scope. We show you how Kubernetes metrics help you keep track of your containers. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Kristin Wittig ## **What are Kubernetes Metrics?** Deployments of Kuberenetes in production are notoriously massive in scope, running thousands and even tens of thousands of containers. Keeping track of this amount of containers can introduce many complexities.  Kubernetes metrics help you keep track of your containers, introducing visibility into the process. Kuberenetes lets you monitor a wide range of metrics and gain insights into your clusters, nodes, pods, and applications. In this blog post, we'll provide you with a short introduction into the world of Kubernetes metrics. ## **Why Monitor Kubernetes?** Kubernetes monitoring is an [essential part of a Kubernetes architecture](https://www.run.ai/guides/kubernetes-architecture/), which can help you gain insight into the state of your workloads. You can monitor performance metrics, resource utilization, and the overall health of your clusters. Insights obtained from monitoring metrics can help you quickly discover and remediate issues. In addition to troubleshooting, Kubernetes monitoring can help you detect threats and protect your workloads. Here are several Kubernetes threats you can monitor: * **Data loss attackers** — attackers use network tunneling and reverse shelling techniques to hide sensitive information * **Rogue pod connection** — attackers with access to compromised containers can connect to other pods. You can detect these attacks through layer 7 network filtering * **Container risk-application vulnerabilities and misconfigurations** — are targeted by attackers, who use these blindspots to discover exploits in networks, systems, files, and process controls ## **Top Kubernetes Metrics to Monitor** Organizations use metrics to measure specific aspects of their Kubernetes deployment. While different production deployments, storage strategies, and networking architectures often require different metrics, to be efficient, a metrics system should be uniform across the entire operation. The below metrics are recommended for the majority of containerized workloads. #### **Kubernetes Cluster Metrics** Your monitoring solution should provide you with relevant insights into the performance of Kubernetes clusters. To gain this level of visibility, you need to keep track of: * The number of running containers, pods, and nodes * Central processing unit (CPU), memory, and disk usage * Network input/output (I/O) pressure This information can help you learn more about capacity and adjust cluster resource utilization accordingly. #### **Kubernetes Control Plane Metrics** In Kubernetes, the process responsible for monitoring clusters is called “Kubernetes Control Plane”. The control plane keeps track of various metrics, and then makes scheduling decisions that ensure the cluster runs optimally. The control plane is controlled by master nodes.  To ensure the control plane works properly and efficiently, you need to collect relevant metrics that track control plane components. For example, you can monitor the Scheduler, application programming interface (API) Server, Etcd, and Controller.  Once you set up these metrics, you should virtualize and centralize the data. You can do that using Grafana dashboards, which can be utilized after you set up Prometheus. These insights can help you troubleshoot cluster performance issues. #### Kubernetes Node Metrics A Kubernetes node has its own pre-determined CPU and memory capacity, which can be used by connected running pods. This process greatly impacts cluster operations, and should be monitored continuously. Here are other additional metrics every Kubernetes monitoring solution should collect and monitor: * Disk-space usage * Node-network traffic Node conditions describe the status of the running nodes and can be of great use. For example, statuses such as MemoryPressure, Ready, DiskPressure, OutOfDisk, NetworkUnavailable, and more. #### Kubernetes Pod/Container Metrics Resource allocation is critical in ensuring that pods and containers run optimally without creating disruptions to application performance. To keep track of this process, you need to ensure that pods are not under or over-provisioned. To discover and troubleshoot these issues, you can set up metrics that check the restart activity of containers and monitor throttled containers.  #### Kubernetes Application Metrics Request Rate, Error Rate, and Duration (RED) metrics can help you ensure Kubernetes services are running ideally, and create dashboards that visualize monitoring in real time. In addition to RED metrics, you should also set up application metrics such as memory, heap, threads, and Java Virtual Machine (JVM). ## **Key Kubernetes Performance Metrics** Here are several metrics you should track to gain visibility into the performance of your Kubernetes deployment: * **Memory utilization** — if a cluster is not properly utilizing memory, the workload performance might decrease. Additionally, Kubernetes terminates pods that exceed their limits. When nodes are not provisioned with sufficient memory resources, kubelet determines there is memory pressure and starts reclaiming resources and might delete pods from the node.  * **CPU utilization** — gaps between a pod’s and node’s configured requests and CPU limits might lead to cluster performance and node throttling. You should set up metrics to ensure pods and nodes are requesting the CPU resources needed for optimal performance.   * **Pod deployments** — monitoring can help ensure a deployment rollout runs the needed amount of pods. During this process, Kubernetes first ascertains how many pods are needed to run the application, and then deploys the pods accordingly. In some cases, the deployment may need all new pods available, but in other cases you might need to enforce a waiting period. * **Desired vs current pods** — manually launching individual pods is usually not efficient when running Kubernetes deployments in production. These scenarios often require the use of controllers, which automatically create pods according to predefined specs. There are several metrics you can use to set up desired pods. For example, kube_deployment_spec_replicas, and kube_deployment_status_replicas. When setting this up, do make sure that the numbers of these pods match. ## **Monitoring Kubernetes in the Cloud** #### **Kubernetes Monitoring on AWS** Amazon Web Services (AWS) offers [several monitoring solutions](https://cloud.netapp.com/blog/aws-blg-aws-monitoring-tools-and-best-practices-monitor-what-matters) you can use when deploying Kubernetes in the cloud, including a dedicated monitoring service called Amazon CloudWatch Container Insights.  Amazon CloudWatch Container Insights is a fully-managed service that lets you isolate, monitor, and diagnose containerized workloads and microservices environments. The service provides automation capabilities, visualized dashboards, and actionable insights you can use to troubleshoot your environment. You can use Amazon CloudWatch Container Insights to automate dashboards and visualize information flowing from a range of services, including Amazon Elastic Container Service for Kubernetes (EKS) and Amazon Elastic Container Service (ECS). Once you collect information from your Kubernetes clusters, you can sort it by node, pod, task, namespace, service, and container. #### **Kubernetes Monitoring on Azure** Microsoft Azure offers a feature called Container insights that lets you monitor the performance of containerized workloads deployed in the Azure cloud or on-premises.  Containers insights enables you to consume logs from several orchestration engines, including Kubernetes, Docker Swarm, Red Hat OpenShift, and DC/OS. You can collect log and metric information from containers running within a cluster and also from cluster hosts, and correlate log information from the two source types. #### **Kubernetes Monitoring on Google Cloud** When you create a new cluster, Cloud Operations for Google Kubernetes Engine (GKE) is enabled by default to provide monitoring capabilities for Kubernetes. Google Kubernetes Engine (GKE) integrates natively with Cloud Logging and Cloud Monitoring, and both services features are managed by Cloud Operations for GKE. Cloud Operations for GKE provides a monitoring dashboard designed especially for Kubernetes. The dashboard lets you view important cluster metrics, including memory usage, CPI utilization, and the total number of open incidents. You can view clusters by workloads, services, or infrastructure, and inspect nodes, namespaces, services, containers, and nodes. #### Kubernetes Metrics with Kubermatic Kubernetes Platform Kubermatic Kubernetes Platform (KKP) manages up to thousands of clusters across multiple private and public clouds. We have designed KKP to provide for Kubernetes automation in large scale and complex enterprise setups. Of course, reliable metrics on health, performance, and resource consumption are an integral part of that. Kubermatic Kubernetes Platform uses best-in-class open source technologies to provide users with centralized Monitoring, Logging, and Alerting of their clusters and services across numerous clouds. KKP uses [Prometheus](https://prometheus.io/) and its [Alertmanager](https://prometheus.io/docs/alerting/alertmanager/) for monitoring and alerting. Dashboarding is done with [Grafana](https://prometheus.io/docs/alerting/latest/alertmanager/). #### Learn More * [Request a demo](https://www.kubermatic.com/demo/) of Kubermatic Kubernetes Platform * Find [Kubermatic Kubernetes Platform](https://github.com/kubermatic/kubermatic) on Github --- ## Deploying Ambassador Edge Stack with Kubermatic KubeOne - **URL:** https://www.kubermatic.com/blog/deploying-ambassador-edge-stack-on-kubernetes-with-kubermatic-kubeone/ - **Date:** 2026-05-07 - **Description:** In this blog post, we show you step by step how you can use Kubermatic KubeOne to deploy Edge Stack on AWS. - **Categories:** Products - **Tags:** KubeOne - **Authors:** Sebastian Scheele [Ambassador Edge Stack](https://www.getambassador.io/products/edge-stack/) is an open-source, Kubernetes-native API Gateway that delivers Edge-as-a-Service to application developers. Built on the powerful Envoy Proxy, it routes and secures traffic to your cluster. Ambassador Edge Stack makes it easy to secure your microservices with a comprehensive set of security functionality, including automatic TLS, authentication, rate limiting, WAF integration, and fine-grained access control. This allows teams to reduce the number of components they need to install and manage, thereby minimizing operational intervention and allowing developer self-service.    On top of that, Edge Stack is quite easy to deploy. In this blog post, we are going to show you step by step how you can use Kubermatic KubeOne to deploy Edge Stack on AWS. The prerequisite for this is that you already have a running KubeOne Kubernetes cluster. In case you do not have one yet, read [this blog post](https://blog.getambassador.io/deploying-ambassador-edge-stack-on-kubernetes-with-kubermatic-kubeone-2c6fa4d58d7d) by Richard Li on how to easily set up your highly-available Kubernetes cluster on AWS to get you started.  ## A Closer Look at Ambassador Edge Stack Ambassador Edge Stack is a proven Kubernetes-native API gateway built on Envoy Proxy.E dge Stack can function as a full-fledged [Kubernetes ingress controller](https://www.getambassador.io/products/edge-stack/api-gateway/kubernetes-ingress-controller/). It also supports a broad range of functionality not supported in the ingress specification, including [traffic management controls](https://www.getambassador.io/products/edge-stack/api-gateway/traffic-management/) such as load balancing and circuit breaking, authentication, and observability. Edge Stack can be installed using [Helm or YAML](https://www.getambassador.io/docs/edge-stack/latest/tutorials/getting-started/). For more advanced configuration options such as TLS termination and Single Sign-On integration with Keycloak, the [K8s Initializer](https://app.getambassador.io/initializer/#configurator-aes) will automatically generate the necessary configuration. Ambassador Edge Stack can be deployed in any cloud provider, or on-premise. In this blog post, we’ll take AWS as an example . For more detailed information, see the Edge Stack documentation on deploying with specific AWS Load Balancers: * [“Classic" Load Balancer (ELB)](https://www.getambassador.io/docs/edge-stack/latest/topics/running/ambassador-with-aws/#classic-load-balancer-elb) * [Network Load Balancer (NLB)](https://www.getambassador.io/docs/edge-stack/latest/topics/running/ambassador-with-aws/#network-load-balancer-nlb) * [Application Load Balancer (ALB)](https://www.getambassador.io/docs/edge-stack/latest/topics/running/ambassador-with-aws/#application-load-balancer-alb). ## Installation In this example we will be using Helm 3 to deploy the Edge Stack. Add the Repo: `helm repo add datawire https://www.getambassador.io` Create Namespace and Install: `kubectl create namespace ambassador && \` `helm install ambassador --namespace ambassador datawire/ambassador && \` `kubectl -n ambassador wait --for condition=available --timeout=90s deploy -lproduct=aes` Congratulations! You have successfully installed The Ambassador Edge Stack! ## Routing Traffic from the Edge Edge Stack empowers developers and devops teams with self-service functionality for managing changes to routing. This includes a declarative policy engine and CRD configurations. Like any other Kubernetes object, Custom Resource Definitions (CRDs) are used to declaratively define Edge Stack’s desired state.  The workflow you are going to build uses a simple demo app and the [Mapping CRD](https://www.getambassador.io/docs/edge-stack/latest/topics/using/intro-mappings/#introduction-to-the-mapping-resource), which is the core resource that you will use with Edge Stack. It lets you route requests by [host](https://www.getambassador.io/docs/edge-stack/latest/topics/running/host-crd/#the-host-crd-acme-support-and-external-load-balancer-configuration) and URL path from the edge of your cluster to Kubernetes services.  Now let’s deploy and expose a sample service. 1. First, apply the YAML for the “Quote of the Moment" service `kubectl apply -f https://www.getambassador.io/yaml/quickstart/qotm.yaml` The Service and Deployment are created in the Ambassador namespace. You can use <kubectl get services,deployments quote --namespace ambassador> to see their status. 2. Copy the configuration below and save it to a file called quote-backend.yaml so that you can create a Mapping on your cluster.  This Mapping tells Edge Stack to route all traffic inbound to the /backend/ path to the quote Service. ```yaml apiVersion: getambassador.io/v2 kind: Mapping metadata: name: quote-backend namespace: ambassador spec: prefix: /backend/ service: quote ``` 3. Apply the configuration to the cluster: `kubectl apply -f quote-backend.yaml` With our Mapping created, now we need to access it! 4. Store the Edge Stack load balancer IP address to a local environment variable. You will use this variable to test accessing your service. `export AMBASSADOR_LB_ENDPOINT=$(kubectl -n ambassador get svc ambassador \` `-o "go-template={{range .status.loadBalancer.ingress}}{{or .ip .hostname}}{{end}}")` 5. Test the configuration by accessing the service through the Ambassador load balancer: `curl -Lk https://$AMBASSADOR_LB_ENDPOINT/backend/` ```bash $ curl -Lk https://$AMBASSADOR_LB_ENDPOINT/backend/    {    "server": "idle-cranberry-8tbb6iks",    "quote": "Non-locality is the driver of truth. By summoning, we vibrate.",    "time": "2021-02-26T15:55:06.884798988Z" } ``` Victory! You have created your first Edge Stack Mapping, routing a request from your cluster's edge to a service! ## Connect your Cluster to Ambassador Cloud The Service Catalog is a web-based interface that lists all of your cluster's services. You can view, add, and update metadata associated with each service, such as the owner, version control repository, and associated Slack channel. 1. Log in to [Ambassador Cloud](https://app.getambassador.io/cloud/catalog) with your GitHub account 2. At the top, hover over All Clusters then click Add a Cluster 3. Follow the prompts to name the cluster and click Generate a Cloud Token. 4. Follow the prompts to install the cloud token into your cluster 5. When the token installation completes, refresh the Service Catalog page Fantastic! You can now see all your services in your Ambassador Cloud account! Metadata on your services about the owner, repo location, etc. can also be shown in Service Catalog via Kubernetes annotations. Continue in the [Service Catalog docs](https://www.getambassador.io/products/service-catalog/) to set annotations on your Services. ## Learn More * Learn how to set up your KubeOne Kubernetes cluster on AWS in [Richard Li's blog post](https://blog.getambassador.io/deploying-ambassador-edge-stack-on-kubernetes-with-kubermatic-kubeone-2c6fa4d58d7d) * Check out the [Ambassador Edge Stack Quick Start](https://www.getambassador.io/docs/edge-stack/latest/tutorials/getting-started/) --- ## Just Released! Kubermatic Kubernetes Platform 2.17 - **URL:** https://www.kubermatic.com/blog/just-released-kubermatic-kubernetes-platform-2-17/ - **Date:** 2026-05-07 - **Description:** KKP 2.17 introduces new etcd backup and restore controllers and Multus CNI support. - **Categories:** Products - **Tags:** KKP - **Authors:** Sascha Haase Today, we are thrilled to announce that Kubermatic Kubernetes Platform (KKP) 2.17 is available, as part of our relentless dedication to the innovation of all things Kubernetes.  The big story for this release is our collaboration with our long-standing client-partner SysEleven, resulting in the new etcd backup and restore controllers that make every operator’s life a whole lot easier. The latest KKP release also comes with Multus CNI support, and a fully-fledged UI integration of the Open Policy Agent (OPA). Let’s take a more detailed look at these and other major improvements. ## **Automated Backups and Restore Operations**  Together with the great SysEleven team, we have developed new etcd and restore controllers that further automate cluster operations. The new controllers utilize CRDs for backups and restore and support multiple backup configurations per cluster, as well as immediate backups. We are very grateful that the community is supporting us to constantly innovate - big thanks go to the SysEleven team for this! To find out more about how to optimize the benefits of the new controllers, check out the [Cheat Sheet](https://docs.kubermatic.com/kubermatic/main/cheat-sheets/etcd/backup-and-restore/) in our documentation. ## **Run Any Cluster Networking Interface With Multus CNI** We have decided to implement Multus CNI for KKP 2.17. [Multus CNI](https://github.com/k8snetworkplumbingwg/multus-cni) is a meta-plug-in for Container Networking Interfaces (CNI) that can run multiple, diverse CNIs. This allows our growing customer base to freely choose between different types of CNIs and configure everything according to their needs. For our early adoption edge customers, Multus CNI makes it much easier to integrate several CNIs in a single cluster and implement SR-IOV support for bandwidth intensive scenarios. ## **One Click Policy Compliance With OPA UI Integration** With the 2.16 release, we introduced Open Policy Agent (OPA) support to enable our users to centrally manage and enforce policies in microservices, Kubernetes, CI/CD pipelines, API gateways, and more in a truly cloud native way. With this new release, OPA is now available as a fully-fledged UI integration, enabling users to implement fine-grained access control step by step. ![Open Policy Agent integration](/static/open-policy-agent-integration-in-kubermatic-kubernetes-platform-2.17.png) ## **Documentation Improvements** As we are always striving to make sure that our users are happy with every aspect of their user experience, we have invested a significant amount of time and effort into improving our documentation. We know; it was high time:).The Kubermatic documentation now comes with a unified format for all of our open source projects, as well as improved top-level navigation. Take a look at our newly introduced Tutorials and How-tos, which will help you to get started more easily, as well as our Guides for more in-depth briefings. ## **Run Kubernetes As You Like** KKP 2.17 supports Kubernetes 1.21, providing our users with access to the latest Kubernetes improvements including graceful node shutdown, and immutable ConfigMaps and Secrets. If you want to take a deeper dive into the Kubernetes universe, take a look at our [detailed blog post.](https://www.kubermatic.com/blog/kubernetes-1-21-is-here/)  If you would like to learn more about this release, the easiest way is to [contact us](https://www.kubermatic.com/contact-us/) or [get in touch](https://www.kubermatic.com/company/community/#discussions) via Github, Slack, or our Twitter. Don’t miss KubeCon Europe Virtual next week! If you would like to join us and you don’t have a ticket, just send us an email to [marketing@kubermatic.com](mailto:marketing@kubermatic.com). We do have a few tickets left – first come, first serve. ## **Learn More** * Check out the entire [Changelog](https://github.com/kubermatic/kubermatic/blob/master/CHANGELOG.md)  * Check out our [introductory webinar](/resources/get-started-with-kubermatic-kubeone/) to get you started with KKP --- ## Announcing SVA as a New Reseller Partner - **URL:** https://www.kubermatic.com/blog/announcing-sva-as-a-new-reseller-partner/ - **Date:** 2026-05-07 - **Description:** Find out more about our partnership with one of the leading German systems integrators for high quality IT products. - **Categories:** Company - **Tags:** Announcements - **Authors:** Carolin Kaps We are very excited to announce a strategic partnership with System Vertrieb Alexander GmbH (SVA), one of Germany’s leading systems integrators for high quality IT products. SVA’s reputation for excellent customer service and IT agility, combined with our well established Kubernetes automation portfolio, will provide customers with optimum solutions for their cloud native deployments at scale. **Benefits of this partnership include:** * **Top skills:** With a team of more than 1,100 specialists in the fields of Agile IT/DevOps, SVA provides a wide range of solutions, all over Germany, to ensure our joint customers get the most value out of their Kubernetes solutions. * **Individualized solutions:** With a focus on understanding customer challenges, our partnership will help clients drive adoption of cloud native solutions and help them succeed in their transformation journey, often with customizations specific to their industry and clientele. * **Strong partnerships:** This partnership represents our continued commitment to enable customers’ optimization process, by offering a wide array of advisory, implementation, managed and technical services together with other vendors of open source products to deliver the newest solutions faster and more efficiently. Our open source Kubermatic Kubernetes Platform (KKP) simplifies Day 2 operations and minimizes the complexity of Kubernetes, by fully automating the management of Kubernetes clusters across multi-cloud, on-premises, edge, and IoT environments. KKP provides DevOps teams with simple self-service Kubernetes to easily build and deploy containerized services everywhere. Together, SVA and Kubermatic deliver next level solutions to help customers realize the benefits of their cloud native progression. And since it’s all about speed and responsiveness, our new partnership has already been chosen recently by a major telecom services company and one of Europe’s largest university hospitals to help them deliver on enhanced customer service, increased revenues and a lower cost of operations! ## **About SVA** SVA System Vertrieb Alexander GmbH is one of the leading German systems integrators. The company – founded in 1997 and based in Wiesbaden/Germany – by now has more than 1.700 employees at 24 branch offices all over Germany. By combining high quality IT products from a variety of vendors, project know-how and agility, SVA provides optimum solutions to customers.  SVA experts combine twenty years of IT infrastructure experience with know-how about modern demands such as data center security 2.0, big data & analytics, workspace of the future, cloud and agile IT & software development. ## **Where to Learn More** * [About SVA](https://www.sva.de/index.html) * Demo: [Automate Your Clusters Across Multi-Cloud with Kubermatic Kubernetes Platform](https://www.kubermatic.com/resources/automate-your-clusters-across-multi-cloud-with-kkp/) * [How to Become a Partner at Kubermatic](https://www.kubermatic.com/partners/) --- ## Running Kubernetes in Production – The Ultimate Checklist - **URL:** https://www.kubermatic.com/resources/the-ultimate-checklist-for-running-kubernetes-in-production/ - **Date:** 2023-08-28 - **Description:** Have you thought of everything that’s important to manage complex Kubernetes scenarios in production? # Running Kubernetes in Production – The Ultimate Checklist ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ![](/static/content-pixie-l6i8jpzkjqu-unsplash_hu_fee8ce5f3ef01b3a.jpeg) Business Case ## Get our ultimate checklist that helps you determine quickly and easily if you are ready to run Kubernetes in production Kubernetes is very powerful, but the path to its adoption isn’t always easy. Even for sophisticated operations teams, it’s a challenge to manage Kubernetes at scale. In enterprise scenarios, workloads are copious and SLA compliance and security are crucial. You already have Kubernetes up and running smoothly in your test environment? Nice! But running it in production requires a lot more attention and due diligence to avoid costly pitfalls.  To help you determine quickly and easily if you are ready to run Kubernetes in production, we’ve created a very handy and comprehensive checklist. It will give you the peace of mind and confidence to move forward and engage in this endeavour. Download our checklist to find out if you: - Have everything set up for availability, resource and storage management - Have provisioned for enterprise-grade security and scalability - Have everything secured for your CI/CD pipeline If our form couldn't load correctly – This can have multiple reasons like ad blocker, not accepted cookies, JavaScript deactivated. However, you can still get in touch with us! Simply click on the button below, and you'll be able to submit the form and reach out to us for any inquiries or assistance you need. [Open form](https://share.hsforms.com/1E0xLpN1eRpu9VjbvJPmFjA2piu8) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## How to Write Operators for Cloud Operators - **URL:** https://www.kubermatic.com/resources/how-to-write-operators-for-cloud-operators/ - **Date:** 2022-12-01 - **Description:** Learn how to design a cloud operator for operators in less than 20 minutes # How to Write Operators for Cloud Operators ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch the Recording of Our Talk at CloudOps Summit 2021 With the rise of Kubernetes popularity across various use-cases, including edge computing, IoT, 5G, or AI/ML, single-cluster Kubernetes deployments are increasingly becoming an exception rather than the norm. As the number of clusters increases, the management of these clusters and the applications running in them quickly becomes the operators’ final boss. In this talk, Sascha Haase will show you how you can master this challenge with open source platforms developed by Kubermatic: Kubermatic Kubernetes Platform for multi-cluster infrastructure management and KubeCarrier for multi-cluster application deployment and management. Come and learn how you can use these tools to master the final boss and automate the full lifecycle of complex multi-cluster solutions consisting of applications spread across multiple Kubernetes clusters. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## How to Write Software That Sets Up Kubernetes Anywhere - **URL:** https://www.kubermatic.com/resources/how-to-write-software-that-sets-up-kubernetes-anywhere/ - **Date:** 2022-12-01 - **Description:** Learn how to use existing tools to write software that sets up Kubernetes anywhere # How to Write Software That Sets Up Kubernetes Anywhere ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch the Video and Learn How We Developed KubeOne to Set Up Kubernetes Anywhere Kubernetes is a complex system. But installing Kubernetes doesn’t need to be hard. In this short clip, our Software Engineer Marko Mudrinić explains how to use existing tools to make tasks easier for you. He provides you with some insights on the learnings we made while creating KubeOne, an open source and infrastructure-agnostic cluster lifecycle management tool for single and HA Kubernetes clusters. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Monitoring, Logging & Alerting - **URL:** https://www.kubermatic.com/resources/monitoring-logging-alerting/ - **Date:** 2022-12-01 - **Description:** Get a brief overview of how a typical monitoring, logging & alerting stack in a Kubernetes cluster looks like # Monitoring, Logging & Alerting ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch This Video About Monitoring, Logging & Alerting Stack in a Kubernetes Cluster In this short clip, our Software Engineer Rastislav Szabo gives a brief overview of how a typical monitoring, logging & alerting stack in a Kubernetes cluster looks like. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Why to Write Operators for Kubernetes - **URL:** https://www.kubermatic.com/resources/why-to-write-operators-for-kubernetes/ - **Date:** 2022-12-01 - **Description:** Find out why writing operators for Kubernetes is a good idea # Why to Write Operators for Kubernetes ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch This Video and Learn More About the Advantages of Kubernetes Operators At Kubermatic, we build software that operates Kubernetes and everything in between. In this short clip, our software engineer Jiacheng Xu explains why writing operators for Kubernetes is a good idea. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Will 5G Bring Containers Anywhere – Even to the Outer Space? - **URL:** https://www.kubermatic.com/resources/will-5g-bring-containers-anywhere-even-to-the-outer-space/ - **Date:** 2026-06-10 - **Description:** Let’s discuss why cloud native is so essential for enterprises and why this technology might be the game changer for a successfully working homeschooling system # Will 5G Bring Containers Anywhere – Even to the Outer Space? ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ![](/static/resource-page_podcast_outer-space_hu_edeb533089ecfcd9.jpg) Podcast ## Will 5G Bring Containers Anywhere – Even to the Outer Space? Let’s talk about the edge again – but in a different setup this time. Role change: the guest of our previous episode, Sriram Vishwanath, CEO & Co-Founder at GenXComm, is our host and welcomes his guests, Sebastian and Sascha. Together, they discuss why cloud native is so essential for enterprises and why this technology might be the game changer for a successfully working homeschooling system. Let’s see if Sriram is as charming a host as he is a guest:) **Also check out:** - [Edge Computing with Kubermatic Kubernetes Platform](https://www.kubermatic.com/solutions/edge-computing/) - [5G on Kubernetes with Kubermatic](/solutions/telecom/) - [Edge Native Podcast](https://www.edge-native.io/) [Listen](https://www.buzzsprout.com/1409671/7650580-06-will-5g-bring-containers-anywhere-even-to-the-outer-space.mp3?blob_id=33817909&download=true) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Keeping the State of Apps Part 2: Introduction to Secrets - **URL:** https://www.kubermatic.com/blog/keeping-the-state-of-apps-part-2-introduction-to-secrets/ - **Date:** 2026-05-07 - **Description:** In this part, you will learn more about secrets. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Seyi Ewegbemi Kubernetes has an integrated pattern for decoupling configuration from application or container to make it portable and make its management flexible. This inbuilt pattern allows application externalisation, as well as giving the application components autonomy from the container image.  Application configuration with Kubernetes makes use of two Kubernetes objects: **Secrets** for sensitive data and **ConfigMaps** for non sensitive data. These objects are used for the external configuration of individual key-pair values by using them as either environment variables or files inside a running container in a Pod. In this part of our Kubernetes 101 series, we will continue with the data preservation by bringing Kubernetes Secrets into the game. The below topics will be covered in this part while ConfigMaps and its functionalities will be covered in the next part of our series.  * How to configure your application * Using files for the configuration of your application * Using environment variables for the configuration of your application * How to make Kubernetes meta info available in your application ## What Is a Kubernetes Secret A Secret in Kubernetes is a Kubernetes object used to secure and hold sensitive data. It protects the sensitive data like passwords, tokens, ssh & API keys, OAuth credentials etc. from unauthorised access and reduces the risk of exposing sensitive data during Pod creation. It has a maximum size of 1MB, and it can be deployed into a Pod as ***volume, environment variables*** or ***kubelet***. During Pod creation, putting sensitive information like usernames, passwords, tokens and keys as plain text in the YAML file is not the best configuration practice in Kubernetes, which is where Kubernetes Secrets come in. ## **Types of Kubernetes Secrets** There are three types of Kubernetes Secrets: 1. **Docker-registry** – Represents the credentials used to authenticate to a container registry 2. **Generic/Opaque** – Represents literal values from different sources 3. **Tls** – Represents a certificate-based Secret ## **Creating a Kubernetes Secret** Kubernetes Secrets can be created in declarative and imperative ways. In the part two of this series, we discuss extensively the  [declarative and imperative ways of creating Kubernetes objects.](https://www.kubermatic.com/blog/kubernetes-as-a-container-orchestration-tool/) ## **Creating a Secret Imperatively and Declaratively** The imperative way of creating a Secret entails passing the commands as flags on the command line using the kubectl command-line tool. The declarative way, on the other hand, involves the creation of Secret configuration data in a manifest file which can either be in YAML or JSON syntax.  The steps below will show you how to create a Secret and inject the Secret into a Pod. You need a running Kubernetes cluster for this exercise together with a kubectl command-line tool. (You can easily create a Kubernetes cluster on any environment with [KubeOne](https://github.com/kubermatic/kubeone#getting-started). Check the [Getting Started](https://github.com/kubermatic/kubeone#getting-started) for instructions. Alternatively, you can use the [Kubernetes playground](https://labs.play-with-k8s.com/) for practising purposes.) ## **Imperative Method by Using Kubectl:** **Step 1:** Create a file to store your username and password on your local machine: ```bash $ echo -n 'admin' > ./username.txt $ echo -n '1t3b2e4f89yz' > ./password.txt ``` **Step 2:** Create the Secret:  ```bash $ kubectl create secret generic my-secret --from-file=./username.txt --from-file=./password.txt\ secret/my-secret created ``` **Step 3:** Check the created Secret: ```bash $ kubectl get secrets my-secret NAME                    TYPE                 DATA         AGE my-secret             Opaque               2           25s ``` A Secret with the name **my-secret** is created with **Opaque** as the Secret type. The data column shows the number of data stored in the Secret, which are 2 (username and password values) in our example. **Step 4:** To see the details of the Secret: ```bash $kubectl describe secrets my-secret Name:        my-secret  ## Name of the Secret as declared in the YAML file Namespace:   default    ## The NameSpace where the Secret is created Labels:      <none> Annotations: <none> Type:  Opaque Data ## The file where the secret will be stored. ==== password.txt:  12 bytes       ## The secured data username.txt:  5 bytes        ## The secured data ``` ## **Declarative or Manual Method of Creating a Secret** **Step 1:** Encode the data by converting it to base 64. ```bash $echo -n 'admin' | base64 Output: YWRtaW4= $echo -n '1t3b2e4f89yz ' | base64 Output: MXQzYjJlNGY4OXl6 ``` **Step 2:** Create a manifest YAML file:  ```bash $ vim secret.yaml ``` **Step 3:** Copy, paste and save the below configuration into your manifest YAML file. ```yaml apiVersion: v1 kind: Secret metadata:   name: mysecret data:   username: YWRtaW4= ## The encoded data   password: MXQzYjJlNGY4OXl6 ``` **Step 4:** Create the Secret using kubectl create: ```bash $ kubectl create -f secret.yaml secret/mysecret created ``` **Step 5:** Check the status of the Secret: ```bash $ kubectl get secret mysecret  NAME           TYPE        DATA   AGE mysecret      Opaque     2      6s ``` **Step 6:** Check the description of the Secret: ```bash $ kubectl describe secret mysecret  ## Where mysecret is the name of the secret.  Name:         mysecret Namespace:    default Labels:       <none> Annotations:  <none> Type:  Opaque Data ==== password:  12 bytes username:  5 bytes ``` ## **How to Decode a Secret** You can decode the Secret (username and password) stored in the application above even after it has been encoded using base 64.  To decode a Secret, copy any of the values from the two fields (username or password) and use the command `echo 'Secret Value' | base64 --decode` to decode it. You can find these values in the Secret manifest YAML file by running the command `kubectl get secret mysecret -o yaml` Follow the below steps to decode the created Secret above: **Step 1**: Get the encoded value using the command: ```bash $ kubectl get secret mysecret -o yaml ``` The output will look like this: ```yaml apiVersion: v1 data:   password: MXQzYjJlNGY4OXl6   username: YWRtaW4= kind: Secret metadata:   creationTimestamp: "2020-08-20T15:23:09Z"   managedFields: apiVersion: v1     fieldsType: FieldsV1 ``` **Step 2:** Copy any of the values and decode it with the below command. In this example, we will decode the password field. ```bash $ echo 'MXQzYjJlNGY4OXl6' | base64 --decode 1t3b2e4f89yz ``` If you look at the output, you will see that it is the same with the password value that was encoded earlier under this topic. ## **How to Mount a Secret Into a Container in a Pod** You can mount a Secret into a Container in a Pod using **volume and volumeMounts** as **files** or **environment variables**. We will walk you through how to use these  two methods. ## **Mounting a Secret as a File in a Pod** You can mount a Secret into a running container in a Pod using files by following the below steps.  The Secret we created earlier will be used for this exercise.  Now that you have your Secret created on the cluster, the next step is to create a Pod that will reference the Secret. **Step 1:** Create a file using vim editor.  ```bash $ vim secret-pod.yaml ``` **Step 2:** Copy, paste, and save the below manifest file and exit the terminal. ```yaml apiVersion: v1 kind: Pod metadata:   name: mypod spec:   containers: name: mycontainer      image: nginx   volumeMounts: name: foo      mountPath: /opt/foo   volumes: name: foo   secret:    secretName: mysecret ``` **Step 3:** Create the Pod: ```bash $ kubectl create -f secret-pod.yaml pod/mypod created ``` **Step 4:** Check the Pod status: ```bash $kubectl get pods mypod $kubectl get pods mypod NAME READY STATUS RESTARTS AGE mypod 1/1 Running 0 19s ``` **Step 5:** Exec into the container to check if you can access the Secret: ```bash $ kubectl exec -ti mypod -- bin/bash root@mypod:/# ``` **Step 6:** Change into the mountPath directory(/opt/foo) from the Pod manifest and check the file in the folder. ```bash $ root@myapp:/# cd /opt/foo root@myapp:/opt/foo#  ``` **Step 7:** You can open the file using `cat` command: ```bash root@mypod:/opt/foo# cat username admin\ root@mypod:/opt/foo# cat password 1t3b2e4f89yz Type exit command to exit from the container.  root@mypod:/opt/foo# exit master $ ``` The Secret has successfully been injected into the container. ## Mount a Secret as Environment Variables in a Pod The below steps will guide you on how to inject a Secret into a Pod using environment variables. You need to first create the Secret before creating the Pod. Then reference the Secret in the Pod by adding the environment variable block, which contains properties such as name, valueFrom among others. We will assume that the Secret has been created. Now, you need to create the Pod. Create the Pod: **Step 1:** Edit the Pod manifest file by removing the volume block and replace it with the environment variables block as it is shown below. ```yaml   env: name: USERNAME           valueFrom:             secretKeyRef:               name: mysecret               key: username name: PASSWORD           valueFrom:             secretKeyRef:               name: mysecret               key: password restartPolicy: Never ``` The complete manifest file will look like this: ```yaml apiVersion: v1 kind: Pod metadata:   name: mypod spec:   containers: name: mycontainer     image: nginx     env: name: USERNAME           valueFrom:             secretKeyRef:               name: mysecret               key: username name: PASSWORD           valueFrom:             secretKeyRef:               name: mysecret               key: password   restartPolicy: Never   ``` **Step 2:** Create the Pod: ```bash $ kubectl create -f secret-pod.yaml pod/mypod created ``` **Step 3:** Check the Pod status: ```bash $kubectl get pods mypod NAME    READY   STATUS    RESTARTS   AGE mypod     1/1    Running      0        19s ``` **Step 4:** Exec into the Pod to check if the Secret has already been injected into the Pod ```bash $ kubectl exec -it mypod -- bin/bash root@mypod:/# ``` **Step 5**: Use echo command to display the username and password. If everything worked correctly, you should see the values of both the username and password inside the container. ```bash $ root@mypod:/# echo $USERNAME $PASSWORD admin 1t3b2e4f89yz  ``` To clean up, delete the Secret and the Pod using kubectl delete command. ```bash $ kubectl delete pod mypod pod/mypod deleted ``` ```bash $ kubectl delete secret mysecret secret/mysecret deleted ``` Congratulations! you have successfully created a Secret and injected it into a Pod by mounting it into a container in a Pod using files and environment variables.  Next in our series, we will guide you through another Kubernetes object known as ConfigMaps which is similar to Kubernetes Secret. Please feel free to [contact us](mailto:marketing@kubermatic.com) with any questions you have on Secret or other Kubernetes objects! ## Learn More * Visit the official [Kubernetes website](https://kubernetes.io/docs/concepts/configuration/secret/) for more resources on Kubernetes Secrets * Learn more about [Kubernetes Secrets practices here](https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/) --- ## Cloud Native as the Common Platform - **URL:** https://www.kubermatic.com/resources/cloud-native-as-the-common-platform/ - **Date:** 2022-12-01 - **Description:** Learn more about how to deploy Kubernetes to different locations to accelerate a distributed architecture. # Cloud Native as the Common Platform ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch the Recording of Our Talk at Enterprise Cloud Native Summit 2021 Typically, resources at the edge are limited. However, the still most common setup is that both, the control plane and the worker, are running on the edge. Why not change this? Why not decouple the control plane and the worker location and run the control plane in the cloud or the datacenter and only the worker on the edge? With this, we can leverage all the resources on the edge for workload and don’t need to block them for the control plane. In this video, we demonstrate how we can deploy Kubernetes to different locations to accelerate such a distributed architecture. ##### Sascha Haase, VP Edge at Kubermatic ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Kubermatic Turns Five! - **URL:** https://www.kubermatic.com/blog/kubermatic-turns-five/ - **Date:** 2026-05-07 - **Description:** This is a special day! Kubermatic turns five! - **Categories:** Company - **Tags:** Announcements - **Authors:** Sebastian Scheele, Julian Hansert Time flies....and all of a sudden your baby is **five years** old! Looking back on the years since our launch in 2016, we are filled with pride, joy, astonishment, and a bit of nostalgia. In early 2016, Kubermatic (or Loodse back then) was not much more than two guys with a gut feeling that Kubernetes could potentially be a big thing, as well as the ambition to build a business model around that. After discussing this rather vague idea on several cycling trips, we didn't hesitate for very long, registered the company, and turned Julian’s living room into our first office.    What followed thereafter can only be described as a crazy rollercoaster ride that sometimes left us dizzy: * In June 2016 we organised the first **ContainerDays** conference, which was attended by over 200 container enthusiasts, in Hamburg harbour. (Looking at ContainerDays' participation numbers today, this seems ridiculous. But in a year where KubeCon Europe had about 400 participants, this clearly felt huge.) * Convinced that organizations would get to a point where they would adopt multiple, rather than single Kubernetes clusters, we launched the beta version of **Kubermatic Kubernetes Platform** (KKP) in February 2017. (Interestingly, multi-cluster deployments are increasingly becoming the standard. But there were times when we asked ourselves if the idea of running hundreds or even thousands of clusters was not a little too crazy). * In May 2017, we received the **German Accelerator Tech** award for exceptionally promising tech startups. This brought us to Silicon Valley for six months, which allowed to grow our network of US-based cloud native companies and gain initial traction overseas. * In May 2018, Kubermatic became one of the first twenty **Kubernetes Certified Service Providers** and **Kubernetes Training Partners**. Just three years later, the cloud native landscape lists 200 KCP and 50 KTP. * One year later, in May 2019 we open sourced **KubeOne** – our Kubernetes lifecycle management tool, which automates deployment and operations for single Kubernetes clusters. * Most recently, the big bang in June last year: We **open sourced our core software Kubermatic Kubernetes Platform** and changed the name of the company from Loodse to Kubermatic. (After four years of trying to explain how Loodse was actually pronounced, we decided to give up). Now, in April 2021, Kubermatic is a **100% open core company** with more than **60 team members** spread across **14 countries** (We'll add Turkey to that list very soon). This is clearly reason enough to thank all of those who made this incredible journey possible: * First and foremost, our thanks go to an **incredible team** full of ideas, proactive energy and team spirit! Keep BALLERN! * Thanks to **all of our customers** for your trust and collaboration. We are totally committed to remain at the forefront of cloud native innovation and deliving the best-in-class solutions that you demand. * In this context, we want to thank **our earliest and original customers** in particular, who were crazy enough to believe that a small start-up would be able to deliver on its promise to help you accelerate your cloud native journey. * We recognize the impact you have had, not only in lines of code, but also when we remember the bad jokes and anecdotes, still being told at every company party. Thanks to our **alumni** who have accompanied us on our journey. * Kubermatic could not be Kubermatic without the extraordinarily exceptional **cloud native community** and the **CNCF** at its heart. Thank you! * Finally, a big thanks to our **friends and family** for their support, loyalty, trust, and open ear over an intensive five years. We could not have come so very far without all of you. Just as in 2016 when everything started we are still hungry, full of energy, and keenly committed to contributing our part to the cloud native story. Looking forward to the years to come! --- ## The Kubernetes Dashboard Evolution - **URL:** https://www.kubermatic.com/blog/the-evolution-of-kubernetes-dashboard/ - **Date:** 2026-05-07 - **Description:** Our Baby Just Turned 5! Time for a Recap on the Kubernetes Dashboard - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Marcin Maciaszczyk, Sebastian Florek In October 2020, the Kubernetes Dashboard officially turned five. As main project maintainers, we barely could believe that so much time has passed since our very first commit to the project. However, looking back with a bit of nostalgia, we had to realize that quite a lot has happened since then. Now it’s due time to celebrate “our baby” with a short recap. ## **How It All Began** The initial idea behind the Kubernetes Dashboard project was to provide the web interface for Kubernetes. We wanted to reflect the kubectl functionality through an intuitive web UI. The big main benefit from using the UI is obviously to be able to quickly see things that do not work as expected (monitoring and troubleshooting). Also, the Kubernetes Dashboard is a great starting point for users that are new to the Kubernetes ecosystem. The very [first commit](https://github.com/kubernetes/dashboard/commit/5861187fa807ac1cc2d9b2ac786afeced065076c) to the Kubernetes Dashboard was made by Filip Grządkowski from Google on 16th October 2015 – just a few months from the initial commit to the Kubernetes repository. Our initial commits go back to November 2015 ([Sebastian committed on 16 November 2015](https://github.com/kubernetes/dashboard/commit/09e65b6bb08c49b926253de3621a73da05e400fd); [Marcin committed on 23 November 2015](https://github.com/kubernetes/dashboard/commit/1da4b1c25ef040818072c734f71333f9b4733f55)). Since that time, we’ve become regular contributors to the project. For the next two years, we will be working closely with the Googlers, eventually becoming main project maintainers ourselves. ![First commit on the Kubernetes Dashboard](/static/image1-1-.png) ![Replications controllers on the Kubernetes Dashboard](/static/image-2-borders.jpeg) ![Workloads overview on the Kubernetes Dashboard](/static/image3-1-.png) As you can see, the initial look and feel of the project were completely different from the current one. We have changed the design multiple times. The same has happened with the code itself. ## **Growing Up - The Big Migration** At [the beginning of 2018](https://github.com/kubernetes/dashboard/pull/2727), we reached a point where AngularJS was getting closer to the end of its life, while the new Angular versions were published quite often. A lot of the libraries and the modules that we were using were following the trend. That forced us to spend a lot of the time rewriting the frontend part of the project to make it work with newer technologies. The migration came with many benefits like being able to refactor a lot of the code, introduce design patterns, reduce code complexity, and benefit from the new modules. However, you can imagine that the scale of the migration was huge. Luckily, there were a number of contributions from the community helping us with the resource support, new Kubernetes version support, i18n, and some other things. After many long days and nights, we finally released the [first beta version](https://github.com/kubernetes/dashboard/releases/tag/v2.0.0-beta1) in July 2019, followed by the [2.0 release](https://github.com/kubernetes/dashboard/releases/tag/v2.0.0) in April 2020 — our baby had grown up. ## **Where Are We Standing in 2021?** Due to limited resources, unfortunately, we were not able to offer extensive support for many different Kubernetes versions. So, we’ve decided to always try and support the latest Kubernetes version available at the time of the Kubernetes Dashboard release. The latest release, [Dashboard v2.1.0](https://github.com/kubernetes/dashboard/releases/tag/v2.1.0) provides support for Kubernetes v1.20. On top of that, we put in a great deal of effort into [improving resource support](https://github.com/kubernetes/dashboard/issues/5232). Meanwhile, we do offer support for most of the Kubernetes resources. Also, the Kubernetes Dashboard supports multiple languages: English, German, French, Japanese, Korean, Chinese (Traditional, Simplified, Traditional Hong Kong). Persian and Russian language translations are currently in work. Moreover, we are working on the support for 3rd party themes and the design of the app in general. As you can see, quite a lot of things are going on. Luckily, we do have regular contributors with domain knowledge who are taking care of the project, updating the Helm charts, translations, Go modules, and more. But as always, there could be many more hands on deck. So if you are thinking about contributing to Kubernetes, keep us in mind. ## **What’s Next** The Kubernetes Dashboard has now been growing and prospering for more than 5 years now. It provides the community with an intuitive Web UI, thereby decreasing the complexity of Kubernetes and increasing its accessibility to new community members. We are proud of what the project has achieved so far, but this is by far not the end. These are our priorities for the future: * Keep providing support for the new Kubernetes versions. * Keep improving the support for the existing resources. * Keep working on auth system improvements. * [Rewrite the API to use gRPC and shared informers](https://github.com/kubernetes/dashboard/pull/5449): This will allow us to improve the performance of the application but, most importantly, to support live updates coming from the Kubernetes project. It is one of the most requested features from the community. * Split the application into two containers, one with the UI and the second with the API running inside. ## **The Kubernetes Dashboard in Numbers** * Initial commit made on October 16, 2015 * Over 100 million pulls from Dockerhub since the v2 release * 8 supported languages and the next 2 in progress * Over 3360 closed PRs * Over 2260 closed issues * 100% coverage of the supported core Kubernetes resources * Over 9000 stars on GitHub * Over 237 000 lines of code ## **Join Us** As mentioned earlier, we are currently looking for more people to help us further develop and grow the project. We are open to contributions in multiple areas, i.e., [issues with help wanted label](https://github.com/kubernetes/dashboard/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22). Please feel free to reach out via GitHub or the #sig-ui channel in the Kubernetes Slack. Learn more about [our upstream contributions and open source projects](https://www.kubermatic.com/company/community/). --- ## Kubernetes 1.21 Is Here! - **URL:** https://www.kubermatic.com/blog/kubernetes-1-21-is-here/ - **Date:** 2026-05-07 - **Description:** The Kubernetes 1.21 release is here! In our blog post, we highlight major improvements and show how and when you benefit from them as a Kubermatic user. - **Categories:** Community, Best Practices - **Tags:** Kubernetes, Open Source Projects - **Authors:** Marko Mudrinić The first Kubernetes release of 2021, Kubernetes 1.21: Power to the Community, is finally here! This release brings many new features, improvements, and fixes. Speaking of numbers, 51 enhancements are included in this release, specifically: * 13 enhancements have graduated beta features to stable * 16 enhancements have graduated alpha features to beta * 20 enhancements have introduced new alpha-level features * 2 features have been deprecated In this blog post, we’ll highlight the most notable improvements of this release and let you know when and how you can benefit from them as a Kubermatic user. For a complete overview on all  of the changes, we recommend you check out the [official release announcement](https://kubernetes.io/blog/2021/04/08/kubernetes-1-21-release-announcement/) and the [1.21 changelog](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.21.md). ## Pod Security Policy Deprecation The Pod Security Policy (PSP) feature is deprecated in Kubernetes 1.21 release. You can continue using Pod Security Policies until the feature is entirely removed with Kubernetes 1.25 release (tentatively planned for mid-2022). Pod Security Policies have been a popular approach for securing Kubernetes clusters. Other tools, like [Open Policy Agent (OPA)](https://www.kubermatic.com/blog/introduction-to-open-policy-agent/), have provided more options for implementing fine-grained access control. Extending and improving Pod Security Policies wasn’t possible, without introducing breaking changes, so it was decided to remove this feature. The Pod Security Policies will be replaced with a new, built-in feature, which will offer more flexibility in the future. Check out [the official FAQ](https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/) for more information about the removal of the PSP feature and its planned replacement. If you’re using Pod Security Policies as part of the Kubermatic Kubernetes Platform (KKP) or Kubermatic KubeOne, stay tuned for the migration guide and recommendations. For KKP, we have already introduced OPA support in the [latest release (2.16)](https://www.kubermatic.com/blog/kubermatic-kubernetes-platform-2-16-is-here/). ## Graceful Node Shutdown Graduating to Beta The Graceful Node Shutdown feature has graduated to Beta and will be enabled by default, starting with Kubernetes 1.21. This feature allows Pods to gracefully terminate during a node shutdown.  Previously, all Pods would be terminated without a grace period, which would allow them to finish their work and terminate safely. This can cause various errors for other workloads and users, like requests being dropped and services becoming unavailable. The Graceful Node Shutdown feature alerts kubelet if the node is being shut down, so it can evict Pods. This is very useful in combination with Preemptible VMs or Spot instances, which can be terminated at any time. It gives kubelet a chance to terminate Pods and get them rescheduled to another node automatically, even if the instance is being terminated by the provider. ## Immutable ConfigMaps and Secrets Are Now Stable Support for immutable ConfigMaps and Secret has graduated to stable with this release. This feature allows you to create ConfigMaps and Secrets that cannot be changed after creation. This is ensured by the Kubernetes API server, if `immutable` is set to `true` on a ConfigMap or a Secret, such as: ```yaml apiVersion: v1 kind: Secret metadata: ... data: ... immutable: true ``` If you want to change an immutable ConfigMap or Secret, you will need to create a new ConfigMap or Secret to do so. If there are Pods using the old object, you’ll have to create new ones for that as well. This is useful in scenarios where you want to disallow/prevent any further changes to the application configuration, once the application has started. ## Kubectl User Experience Improvements This release includes several user experience improvements in kubectl. Starting with this release, `kubectl get -o yaml` will not show the managed fields, which makes reading and parsing the output much easier. Additionally, there’s a new annotation, `kubectl.kubernetes.io/default-container`, which can be applied to pods in order to preselect the default container for kubectl commands. ## Structured Logging There’s a lot of ongoing work to structure logs for all Kubernetes components. Structured logs ensure that log messages will be standardized across all components. It’ll also be possible to have logs in the JSON format. Many components have already been migrated to the structured logging in Kubernetes 1.21 release, and it’s expected that the remaining components will migrate in the Kubernetes 1.22 release. ## Kubernetes 1.21 Support in Kubermatic Products At Kubermatic, we are very committed to always support the latest Kubernetes version, to provide our users with access to the latest Kubernetes improvements and features as quickly as possible. Kubermatic Kubernetes Platform 2.17, planned for mid April, will support Kubernetes 1.21. Starting with the [1.2 release](https://www.kubermatic.com/blog/kubeone-1-2-is-ga/), already available, Kubermatic KubeOne supports Kubernetes 1.21. ## Learn more * [Official Kubernetes 1.21 release announcement](https://kubernetes.io/blog/2021/04/08/kubernetes-1-21-release-announcement/)  * [Kubernetes 1.21 changelog ](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.21.md) * [Demo: Open Policy Agent with Kubermatic Kubernetes Platform](https://www.kubermatic.com/resources/opa-integration-in-kubermatic-kubernetes-platform-2-16/) --- ## Bringing Your VMs to Kubernetes With KubeVirt - **URL:** https://www.kubermatic.com/blog/bringing-your-vms-to-kubernetes-with-kubevirt/ - **Date:** 2026-05-07 - **Description:** Learn more about how to manage containers and virtual machines side by side on one underlying Kubernetes infrastructure with the open source project KubeVirt. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Irina Lindt This article is dedicated to the open source project KubeVirt.io, which allows you to bring your virtual machine workloads to Kubernetes. A second part will explain how to use it with Kubermatic Kubernetes Platform. ## What Is KubeVirt? KubeVirt allows your virtual machine workloads to be run as pods inside a Kubernetes cluster. This allows you to manage them with Kubernetes without having to convert them to containers. ## Why Do We Need KubeVirt? Do you have a project running in VMs which you don’t want to convert to containers? Perhaps because it’s a legacy project for which you don’t want to go through the effort and expense of converting, but you’d like to orchestrate them with Kubernetes anyway?  Do you have a project for which you require the special features of VMs? In these cases, KubeVirt is the answer for you! ## Trying It Out This tutorial will guide you through the installation of KubeVirt with Minikube. Minikube allows you to run Kubernetes on your local computer. A second part will show you how to use KubeVirt with Kubermatic Kubernetes Platform. ### Install minikube First, you have to follow the [installation instructions](https://minikube.sigs.k8s.io/docs/start/) to install minikube. Then start it with: ```bash minikube start ``` You should see this output: ```bash 😄 minikube v1.17.1 on Darwin 11.2.3 ✨ Using the docker driver based on user configuration 👍 Starting control plane node minikube in cluster minikube 🚜 Pulling base image ... 💾 Downloading Kubernetes v1.20.2 preload ... > preloaded-images-k8s-v8-v1....: 491.22 MiB / 491.22 MiB 100.00% 3.84 MiB 🔥 Creating docker container (CPUs=2, Memory=1989MB) ... 🐳 Preparing Kubernetes v1.20.2 on Docker 20.10.2 ... ▪ Generating certificates and keys ... ▪ Booting up the control plane ... ▪ Configuring RBAC rules ... 🔎 Verifying Kubernetes components... 🌟 Enabled addons: storage-provisioner, default-storageclass ▪ Want kubectl v1.20.2? Try 'minikube kubectl -- get pods -A' 🏄 Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default ``` You can use kubectl as usual in minikube, but you have to preface any command with minikube and put a -- after kubectl. Example: the regular `kubectl get pods` becomes `minikube kubectl -- get pods`. ### Enable Addon Now you have to enable the KubeVirt addon: ```bash minikube addons enable kubevirt ``` ```bash - Using image bitnami/kubectl:1.17 * The 'kubevirt' addon is enabled ``` You can now use KubeVirt! Check if the resources have been created correctly: ```bash minikube kubectl -- get all -n kubevirt ``` You should see 7 pods, 3 services, 1 daemonset, 3 deployment apps, and 3 replica sets. It might take some time for all the objects to be ready and running. ```bash NAME READY STATUS RESTARTS AGE pod/virt-api-6bb566bbc7-crspt 1/1 Running 0 28m pod/virt-api-6bb566bbc7-fh5jg 1/1 Running 0 28m pod/virt-controller-5d6975c644-j4mbp 1/1 Running 2 28m pod/virt-controller-5d6975c644-r6w7r 1/1 Running 3 28m pod/virt-handler-brxxs 1/1 Running 2 28m pod/virt-operator-976969b94-hsrpb 1/1 Running 2 30m pod/virt-operator-976969b94-k78wh 1/1 Running 2 30m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubevirt-operator-webhook ClusterIP 10.102.7.174 <none> 443/TCP 28m service/kubevirt-prometheus-metrics ClusterIP 10.102.43.88 <none> 443/TCP 28m service/virt-api ClusterIP 10.111.29.61 <none> 443/TCP 28m NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE daemonset.apps/virt-handler 1 1 1 1 1 NODE AGE kubernetes.io/os=linux 28m NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/virt-api 2/2 2 2 28m deployment.apps/virt-controller 2/2 2 2 28m deployment.apps/virt-operator 2/2 2 2 30m NAME DESIRED CURRENT READY AGE replicaset.apps/virt-api-6bb566bbc7 2 2 2 28m replicaset.apps/virt-controller-5d6975c644 2 2 2 28m replicaset.apps/virt-operator-976969b94 2 2 2 30m NAME AGE PHASE kubevirt.kubevirt.io/kubevirt 30m Deployed ``` ### Install virtctl Run the following to install virtctl, a tool to explore graphical ports of the VM: ```bash VERSION=$(kubectl get kubevirt.kubevirt.io/kubevirt -n kubevirt -o=jsonpath="{.status.observedKubeVirtVersion}") ARCH=$(uname -s | tr A-Z a-z)-$(uname -m | sed 's/x86_64/amd64/') || windows-amd64.exe echo ${ARCH} curl -L -o virtctl https://github.com/kubevirt/kubevirt/releases/download/${VERSION}/virtctl-${VERSION}-${ARCH} chmod +x virtctl sudo install virtctl /usr/local/bin ``` ### Create a VM Resource Now create a file locally named vm.yaml, then copy and paste the below configuration into the file. Use `minikube kubectl create -f vm.yaml` to create the VM resource on the cluster: ```yaml apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachine metadata: name: testvm spec: running: false template: metadata: labels: kubevirt.io/size: small kubevirt.io/domain: testvm spec: domain: devices: disks: - name: containerdisk disk: bus: virtio - name: cloudinitdisk disk: bus: virtio interfaces: - name: default bridge: {} resources: requests: memory: 64M networks: - name: default pod: {} volumes: - name: containerdisk containerDisk: image: quay.io/kubevirt/cirros-container-disk-demo - name: cloudinitdisk cloudInitNoCloud: userDataBase64: SGkuXG4= ``` Alternatively, you can download the manifest directly from Github using: ```bash wget https://raw.githubusercontent.com/kubevirt/kubevirt.github.io/master/labs/manifests/vm.yaml ``` Then apply it to the cluster using the command: ```bash minikube kubectl -- apply -f https://raw.githubusercontent.com/kubevirt/kubevirt.github.io/master/labs/manifests/vm.yaml virtualmachine.kubevirt.io "testvm" created virtualmachineinstancepreset.kubevirt.io "small" created ``` Use `kubectl get` to check the VM status: ```bash $ kubectl get vms NAME AGE VOLUME testvm 12m ``` You can get more information about the created “testvm” using: ```bash $ kubectl get vms -o yaml testvm ``` ### Starting a Virtual Machine You can start a virtual machine by using virtctl: ```bash ./virtctl start testvm ``` Alternatively, you can use `kubectl patch`: ```minikube '{"spec":{"running":true}}' ``` Check if the virtual machines are running: `minikube kubectl -- get vms` ```bash NAME AGE RUNNING VOLUME testvm 5s false ``` Peradventure the “Running” column is missing, you can use kubectl describe to check if the VM is running. The output will look like this: ```bash $ kubectl describe vm ``` ```yaml Spec: Running: true Template: Metadata: Creation Timestamp: <nil> Labels: kubevirt.io/domain: testvm kubevirt.io/size: small ``` Now that the vm is running, you can check the status. The status could come in three phases which are: ```bash $ kubectl get vmis NAME AGE PHASE IP NODENAME testvm 50s Scheduling ``` ```bash $ kubectl get vmis NAME AGE PHASE IP NODENAME testvm 3m43s Scheduled minikube ``` ```bash $ kubectl get vmis NAME AGE PHASE IP NODENAME testvm 14m Running 172.17.0.11 minikube ``` **Scheduling:** This is the beginning of the phases where the VM components are provisioned.  **Scheduled:** The status changes to “scheduled” after a few minutes which also signals that the node is ready by outputting the node name.  **Running:** This is the final stage where all the components have been provisioned by outputting the IP address. As seen above, you are able to access your virtual machines with kubectl just like you would be able to with pods. **Clean-Up: Shutdown and delete** To stop your virtual machine run: ``` ./virtctl stop testvm VM testvm was scheduled to stop ``` To delete the VM entirely, execute: ```minikube virtualmachine.kubevirt.io "testvm" deleted ``` Stop minikube after you are done with the tutorial: `minikube stop` Delete minikube: minikube delete --all * Successfully deleted all profiles <!--StartFragment--> ## Conclusion This is the first part of this blog post. The next part will guide you through using KubeVirt with Kubermatic Kubernetes Platform. ## Where to Learn More * Read more on how to use KubeVirt on the [official documentation page](https://kubevirt.io/labs/kubernetes/lab1) * Learn more on [KubeVirt here](https://kubernetes.io/blog/2018/05/22/getting-to-know-kubevirt/) * Read more on how the [KubeVirt upgrade](https://kubevirt.io/labs/kubernetes/lab3.html) works --- ## Kickstart Kubernetes Projects With Amazon EKS-D & KubeOne - **URL:** https://www.kubermatic.com/resources/kickstart-your-kubernetes-projects-with-amazon-eks-d-and-kubeone/ - **Date:** 2024-03-22 - **Description:** Learn more about how to set up your very own cluster running EKS-D with Kubermatic KubeOne. # Kickstart Your Kubernetes Projects With Amazon EKS-D and KubeOne ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Watch the Recording of Our Joint Webinar With AWS Tired of Kubernetes the hard way? With the recently announced Amazon EKS Distro (EKS-D) and Kubermatic KubeOne, deploying and managing secure and reliable Kubernetes clusters becomes a piece of cake. With EKS-D, you can rely on the same versions of Kubernetes and its dependencies as deployed by Amazon EKS.  In this session, Michael Hausenblas (AWS) and Mario Fahland (Kubermatic) take a closer look at EKS-D and dive into how to set up your very own cluster running EKS-D with KubeOne – our open source and infrastructure agnostic Kubernetes cluster lifecycle management tool. Also, we have a peek into the future and show how to bring EKS-D to your data centers so you can use the very same tooling on-premises and in the cloud. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## KubeOne 1.2 is GA! - **URL:** https://www.kubermatic.com/blog/kubeone-1-2-is-ga/ - **Date:** 2026-05-07 - **Description:** The latest release of our cluster lifecycle management tool introduces many community-driven improvements and paves the way for upcoming features. - **Categories:** Products, Community - **Tags:** KubeOne, Open Source Projects - **Authors:** Marko Mudrinić Today, we are thrilled to announce **general availability of KubeOne 1.2**. The latest release of our open source cluster lifecycle management tool focuses on **community-driven improvements** and paves the way for upcoming releases that incorporate even more features. We have been adding quite some alpha-level features that will be improved and graduated in the near future.\ \ Since we had to introduce a couple of **breaking changes** to improve the user experience, please carefully read the **Attention Needed** section below.  ## Run Kubernetes 1.20 Ongoing support for the latest [Kubernetes version](https://kubernetes.io/blog/2020/12/08/kubernetes-1-20-release-announcement/) gives users access to the latest Kubernetes features and improvements. We’d like to highlight the following changes: * Docker (Dockershim) is deprecated (read more about this in the containerd section) * Volume Snapshot advances the application and cluster level backups  * `kubectl` debug facilitates debugging any Kubernetes workflow * Exec Probe timeouts are now handled properly. Previously, Exec Probes had no timeout if it was not explicitly specified. With this release, all Exec Probes that don’t explicitly specify the timeout will have the default timeout of one second. So make sure to adjust your Exec Probes accordingly if you’re using those * API Priority and Fairness (APF) allows the Kubernetes API server to categorize incoming requests by priority levels  ## Provision Your Clusters With Containerd  As of Kubernetes 1.20, Dockershim — a component that connects Kubelet and Docker, is deprecated. Starting with Kubernetes 1.23, it will not be possible to use Docker on Kubernetes nodes anymore. Instead, a Container Runtime Interface (CRI) compatible container runtime like containerd must be used. Starting with this KubeOne release, you can provision clusters using containerd. We’ll also provide a migration path for existing clusters created by KubeOne in one of the upcoming releases. Basically, there are two key things that you should know: * KubeOne will install containerd by default on all freshly created clusters using Kubernetes 1.21+ (it’s possible to opt-out as long as Docker is still supported) * We recommend using containerd for all newly created clusters regardless of the Kubernetes version. This will save you time from migrating to containerd once Docker support is removed. This can be easily done via KubeOne configuration manifest: ```yaml apiVersion: kubeone.io/v1beta1 kind: KubeOneCluster ... containerRuntime: containerd: {} ``` For more information about this change, please read the [official announcement and FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/). ## Easily Define Your Static Worker Nodes via Terraform Until now, you could not define Static Worker nodes only via the KubeOne configuration manifest. We got many requests to make it possible to source information about Static Workers from the Terraform state, just like for the control plane instances. With KubeOne 1.2, this is finally possible! We’ve updated our AWS example Terraform config to show you how to use this feature. Check out [this link](https://github.com/kubermatic/kubeone/blob/0476db5f21ec8fdd48a6ba80ab2236b2d2ebae19/examples/terraform/aws/output.tf#L49-L65) to learn more.  Note that we highly recommend using [Kubermatic machine-controller](https://docs.kubermatic.com/kubeone/v1.2/workers/machine_controller/) for managing worker nodes if your provider is [officially supported](https://docs.kubermatic.com/kubeone/v1.2/compatibility_info/). ## Create Reliable and Secure Kubernetes Clusters With Amazon EKS-D KubeOne 1.2 brings alpha-level support for the Amazon EKS Distribution (EKS-D). With EKS-D, you can rely on the same versions of Kubernetes and its dependencies deployed by Amazon EKS. This includes the latest upstream updates as well as extended security patching support. You can learn more about how to use KubeOne to provision and maintain the EKS-D clusters in [this demo](https://www.kubermatic.com/resources/demo-get-started-with-eks-distro-in-less-than-5-minutes/) or in this [blog post](https://www.kubermatic.com/blog/get-started-with-eks-d-at-the-speed-of-light-with-kubermatic-kubeone/). ## Attention Needed — Breaking Changes Stability and user experience are one of the most important values for us. We pay a lot of attention to ensuring that we don’t introduce breaking changes that would affect users. However, this time we had to introduce a couple of such changes to improve the user experience and pave the way for upcoming features. Please check out the Attention Needed section in the [changelog](https://github.com/kubermatic/kubeone/blob/master/CHANGELOG.md#v120---2021-03-18) for more information. We would like to particularly highlight the following change. #### `kubeone reset` will require explicit confirmation starting with KubeOne 1.3 `kubeone reset` is the most destructive command — it reverts everything done by other KubeOne commands. As such, users should be able to explicitly confirm that they want to run it on the provided instances. Starting with the next KubeOne release (1.3), the `kubeone reset` command will ask for explicit confirmation by typing `yes`. It will work in the same way as the `kubeone apply` command. It will output which instances will be affected, followed by the confirmation request. If you’re using the `kubeone reset` command in scripts and want to automatically confirm it, you can use the `auto-approve` flag. The flag is already implemented in this release as a no-op flag, so you can already start modifying your scripts. We hope you like the improvements brought by this release and are looking forward to further growing and improving this project. Feel free to [share your ideas and thoughts](https://www.kubermatic.com/company/community/#discussions) via Github or Slack.  ## Read more * Check out the entire [changelog](https://github.com/kubermatic/kubeone/blob/master/CHANGELOG.md#v120---2021-03-18) * Watch [the demo](https://www.kubermatic.com/resources/demo-get-started-with-eks-distro-in-less-than-5-minutes/) on how to get started with EKS-D and KubeOne --- ## Using Kubernetes And GNS3 for Virtual 4G Simulation - **URL:** https://www.kubermatic.com/blog/virtual-4g-simulation-using-kubernetes-and-gns3/ - **Date:** 2026-05-07 - **Description:** Learn how to simulate a 4G stack using open source tools including GNS3, Kubernetes and Calico CNI. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Christopher Adigun This blog post is about how to deploy a virtual 4G stack using GNS3 and Kubernetes. It covers the following: * Open5gs vEPC OAI UE and eNodeB simulator * Kubernetes 1.17.3 * Calico CNI * Vyos Router * GNS3 (This is optional, it makes simulations easier) The motivation for this blog post stems from the fact that I worked as a Packet core support engineer 3 years ago before I moved into cloud native with a focus on Kubernetes. So I decided to see if I could simulate a 4G stack using open source tools. I hope you find this interesting as I did! **Note:** Some familiarity with Kubernetes and Telecommunication network is assumed. GNS3 was chosen as a platform to deploy everything because it makes it easy to see everything at a glance and still interact with the components. While Telecom networks remain largely the same logically, the implementation usually is not the same. No two telecom network implementations are generally the same.Take the points below as just one way of implementation. There are many ways to do this especially when Kubernetes is used. * The S1AP of the MME was exposed directly at the POD layer instead of using a service. This point is really subject to how the EPC software is developed. I chose to go this route since this avoids the requirements of enabling the SCTP flag in the Kubernetes API server, so the eNodeB connects directly to the POD instead of via a service. * Calico was used at this stage as CNI. This gives the possibility of advertising the POD IPs directly into your L3 network. This is quite interesting in my opinion. Calico was able to advertise the POD IPs into the Vyos router, which made the routing between the eNodeB and EPC network seamless. The GNS3 network diagram is shown below: ![GNS3 network diagram](/static/pasted-image-0.png) Logical topology is shown below: ![GNS3 network topology](/static/pasted-image-0-1-.png) The UE and eNodeB simulators are running in the same VM while the virtual EPC stack is running in the kubernetes cluster. ### Kubernetes Setup This was installed using the official Kubeadm installation documentation, Calico was used for the CNI. ### vEPC Setup The vEPC was installed using the Open5gs software.It provides the following components: * HSS Database: MongoDB is used for this purpose (deployed as a statefulset). * Web-UI: Web interface to administer the MongoDB database.This is used to add subscriber information. * HSS (deployed as a statefulset) * PGW: It combines both PGW-C and PGW-U (deployed as a statefulset) * SGW: It combines both SGW-C and SGW-U (deployed as a statefulset) * MME (deployed as a statefulset) * PCRF (deployed as a statefulset) It uses the freeDiameter project for the components that require diameter (PGW--PCRF, HSS---MME). A single docker image was used for all the vEPC core components (excluding the MongoDB and Web-UI). Utilizing a dedicated image for each of the core EPC components may be desirable, especially to reduce the overall image size. The manifest files can be found in the repo: [https://bitbucket.org/infinitydon/virtual-4g-simulator/src/master/open5gs](https://bitbucket.org/infinitydon/virtual-4g-simulator/src/master/open5gs/)/ * Create the open5gs namespace: kubectl create ns open5gs * Deploy all the manifest files:\ kubectl apply -f hss-database/ (it is adviseable to wait for the MongoDB POD to be running before proceeding with the rest)\ kubectl apply -f hss/\ kubectl apply -f mme/\ kubectl apply -f sgw/\ kubectl apply -f pgw/\ kubectl apply -f pcrf/ * Status after applying the manifests: ![GNS3 network: status after applying the manifests ](/static/pasted-image-0-2-.png) OpenAirInterface Simulator The basic simulator was used. The full documentation can found via: <https://gitlab.eurecom.fr/oai/openairinterface5g/blob/master/doc/BASIC_SIM.md> Branch v1.2.1 was used. OpenAirInterface SIM details is configured via the following file: “$OPENAIR_HOME/openair3/NAS/TOOLS/ue_eurecom_test_sfr.conf” *IMSI="208930100001111";* *USIM_API_K="8baf473f2f8fd09487cccbd7097c6862";* *OPC="e734f8734007d6c5ce7a0508809e7e9c";* Subscriber details need to be added to the HSS-DB (MongoD). This can be done via the web-ui POD. kubectl port-forward can be used to access the UI locally. \ kubectl -n open5gs port-forward --address=10.10.10.2 svc/open5gs-webui 8888:80 ![GNS3 network: Subcriber Configuration](/static/pasted-image-0-3-.png) You should adapt the forwarding parameters depending on how you want to do this. The eNodeB is initialized using the following: *cd oasim_repo_folder* *source oaienv* *cd cmake_targets/lte_build_oai/build* ENODEB=1 sudo -E ./lte-softmodem -O $OPENAIR_HOME/ci-scripts/conf_files/lte-fdd-basic-sim.conf --basicsim > enb.log 2>&1 The UE is initialized using the following: *cd oasim_repo_folder* *source oaienv* *cd cmake_targets/lte_build_oai/build* *../../nas_sim_tools/build/conf2uedata -c $OPENAIR_HOME/openair3/NAS/TOOLS/ue_eurecom_test_sfr.conf -o .* *sudo -E ./lte-uesoftmodem -C 2625000000 -r 25 --ue-rxgain 140 --basicsim > ue.log 2>&1* OpenAirInterface Interfaces After eNodeB and UE are running ![GNS3 network: OpenAirInterface](/static/pasted-image-0-4-.png) oaitun_enm1-eNodeB interface (UE will connect to it, they are in the same IP network) oaitun_uem1-UE interface towards the eNodeB oaitun_ue1-UE interface that is used to communicate to the PGW, OAI will assign the PGW allocated UE IP address which is 45.45.0.2 in this case. Open5gs MME Status After eNodeB and UE are running: ![](/static/pasted-image-0-5-.png "GNS3 network: Open5gs MME Status After eNodeB and UE are running") Open5gs PGW Status After eNodeB and UE are running: ![Open5gs PGW Status After eNodeB and UE are running](/static/pasted-image-0-6-.png) UE imsi and IP address can be seen above, this matches what is in the UE configuration/status PING Tests From UE to PGW: ![PING Tests From UE to PGW](/static/pasted-image-0-7-.png) PING Tests From UE To The Internet Via PGW: ![PING Tests From UE To The Internet Via PGW](/static/pasted-image-0-8-.png) In conclusion, the following points should also be noted: * Operators might help with the life-cycle management of EPC components especially since the Kubernetes design will ultimately be influenced by how EPC vendors engineer their solutions. * NAT translation was implemented in the PGW pod, this can be offloaded to a CG-NAT solution. The routing implementation will have to be re-designed since the PGW IP-POOL will have to be advertised one way or the other. Vyos can also be used for this purpose. * Calico-vpp integration is currently ongoing, this will give some improvement in the data-plane especially where SR-IOV is not feasible (already cloud platforms like AWS have enhanced network adapters/instances that can further improve the performance) ### Learn More <https://docs.projectcalico.org/reference/resources/bgppeer#bgp-peer-definition> https://gitlab.eurecom.fr/oai/openairinterface5g/blob/master/doc/BASIC_SIM.md <https://www.gns3.com/> <https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/> --- ## OPA Integration in Kubermatic Kubernetes Platform (KKP) 2.16 - **URL:** https://www.kubermatic.com/resources/opa-integration-in-kubermatic-kubernetes-platform-2-16/ - **Date:** 2022-12-01 - **Description:** Learn more about how to use Open Policy Agent for policy making on a Kubernetes cluster managed by Kubermatic Kubernetes Platform. # OPA Integration in Kubermatic Kubernetes Platform 2.16 ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Enterprise-Grade Policy Compliance With Open Policy Agent Keeping your entire technology stack compliant with your organization’s policies can be an operational nightmare. Kubermatic Kubernetes Platform (KKP) 2.16 introduces an out-of-the-box integration of the Open Policy Agent (OPA) that enables you to centrally manage and enforce policies in microservices, Kubernetes, CI/CD pipelines, API gateways, and more. In this demo, we will show you how KKP integrates OPA and how we allow users to create and manage the policies on the seed master clusters of KKP. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Installing Kubermatic Kubernetes Platform - **URL:** https://www.kubermatic.com/blog/installing-kubermatic-kubernetes-platform/ - **Date:** 2026-05-07 - **Description:** Learn more about how to set up Kubermatic Kubernetes Platform from scratch on AWS. - **Categories:** Products - **Tags:** KKP - **Authors:** Sascha Haase Following our two blog posts on Getting Started with Kubermatic Kubernetes Platform: [Automated Multi-Cluster Kubernetes Lifecycle Management ](/blog/automated-multi-cluster-kubernetes-lifecycle-management/)and [Deploying a Kubernetes Cluster with Kubeone](/blog/quick-and-easy-kubernetes-deployments-with-kubeone/), now, we will take you on a deep dive on how to install Kubermatic Kubernetes Platform (KKP) on an existing Kubernetes cluster in the third and last part of this series. In our previous blog posts, you have already learned about how KKP provides full lifecycle management for thousands of Kubernetes clusters with automated deployments, upgrades, and policy compliance across any infrastructure. Based on this, you have gained insights into using KubeOne to create the initial cluster needed for setting up KKP. In this third part, you will learn how to install Kubermatic Kubernetes Platform on an existing Kubernetes cluster by covering the topics below:  * Understand the KKP Architecture * Install Kubermatic Community Edition (CE) on AWS * Set up Seed cluster  ## Understand the KKP Architecture KKP architecture has two main components: **Master Cluster:** This runs the main KKP namespace components that are considered as the main components for Kubermatic Dashboard, such as Kubermatic API and Kubermatic controller manager. **Seed Cluster:** This runs the control plane of the Kubernetes such as API server, scheduler, machine controller, etc. Generally, the KKP architecture supports large-scale multi-cloud deployment of Kubernetes clusters where the master cluster, the seed clusters, and the customer clusters can all be deployed in a different region. ![KKP Architecture](/static/blog-post_getting-started-with-kubermatic-kubernetes-platform-part-3_kkp-architecture.png) ## Installing Kubermatic Kubernetes Platform Community Edition (CE) on AWS Kubermatic Kubernetes Platform Community Edition (CE) is an open-source enterprise software that automates Kubernetes operations across all infrastructure in one single UI.  For setting up a KKP CE master cluster, we can use the following: * The GitHub [repo](https://github.com/kubermatic-labs/k8c-install-webinar) where we’ll find a script `generate.sh` that will further create three files, such as `Kubermatic.yaml`, `seed.yaml`, and `values.yaml`. * The [official Kubermatic installation documentation](https://docs.kubermatic.com/kubermatic/v2.15/installation/) where we can find the two links: * Install Kubermatic Kubernetes Platform CE, and * Add Seed Cluster for CE Before installing KKP, we will need to ensure: * Kubernetes cluster meets the [minimal requirements](https://docs.kubermatic.com/kubermatic/v2.15/requirements/) * Kubectl and Helm are installed locally * Kubeconfig file is at hand Download the [tarball](https://github.com/kubermatic/kubermatic/releases/) that contains the Kubermatic installer and the required Helm charts for the underlying OS  with the below commands: ```bash # For latest version: VERSION=$(curl -w '%{url_effective}' -I -L -s -S https://github.com/kubermatic/kubermatic/releases/latest -o /dev/null | sed -e 's|.*/v||') # For specific version set it explicitly: # VERSION=2.15.x wget https://github.com/kubermatic/kubermatic/releases/download/v${VERSION}/kubermatic-ce-v${VERSION}-linux-amd64.tar.gz tar -xzvf kubermatic-ce-v${VERSION}-linux-amd64.tar.gz ``` KKP installation requires two important files, which are: 1. `values.yaml`: This is used to configure several Helm charts. 2. `kubermatic.yaml`: Instance of the [KubermaticConfiguration](https://docs.kubermatic.com/kubermatic/v2.16/concepts/kubermaticconfiguration/) CRD and is configured by KKP itself. In KKP, a custom storage class is used for the volumes that are created for user clusters. The class, ***`Kubermatic-fast,`*** must be created before the installation. The installer can also create an SSD-based storage class automatically or copy the default StorageClass. However, the latter is not recommended if the default class is not an SSD-based class. You can read more on [StorageClass](https://www.kubermatic.com/blog/keeping-the-state-of-apps-1-introduction-to-volume-and-volumemounts/) in our Kubernetes 101 series blog post. The essential items to configure are: * The base domain under which KKP shall be accessible (e.g., `kubermatic.example.com`). * **The certificate issuer:** KKP requires that its dashboard and Dex are only accessible via HTTPS, so a certificate is required. By default, cert-manager is used, but you have to choose between the production or staging “Let’s Encrypt services” (if in doubt, choose the production server). * For proper authentication, shared secrets must be configured between Dex and KKP. Likewise, Dex uses yet another random secret to encrypt cookies stored in the users' browsers. The secret must be generated twice; the first one will be the **issuerCookieKey** field’s value, while the second one will be assigned to the ***serviceAccountKey*** field in the ***kubermatic.yaml*** manifest file. Finally, on configuration, the ***kubermatic client*** secret value configured in the ***values.yaml*** must be the same as the value of the ***issuerClientSecret*** field in the ***kubermatic.yaml.*** These guidelines are specified in the source codes as comments. The secret keys mentioned above can be generated using any password generator or on the shell using: ```bash cat /dev/urandom | tr -dc A-Za-z0-9 | head -c32. On MacOS, use brew install gnu-tar and cat /dev/urandom | gtr -dc A-Za-z0-9 | head -c32. ``` Once the installation files are ready, we can run the installer that will validate all files and install the required components into the cluster by running the following commands on a terminal: ```bash ./kubermatic-installer deploy \ --config kubermatic.yaml \ --helm-values values.yaml \ --storageclass aws ``` **NOTE:** Ensure that the downloaded file names are the same as the name of the config and helm-values yaml files. If this is not the case, make a copy of the files and rename it as desired, in this case, to ***kubermatic.yaml*** and ***values.yaml***. If everything works fine, the output should look like below: ```bash INFO[13:03:33] 📝 Applying Kubermatic Configuration… INFO[13:03:33] ✅ Success. INFO[13:03:33] 📡 Determining DNS settings… INFO[13:03:33] The main LoadBalancer is ready. INFO[13:03:33] INFO[13:03:33] Service: nginx-ingress-controller / nginx-ingress-controller INFO[13:03:33] Ingress via hostname: EXAMPLEEXAMPLEEXAMPLEEXAMPLE-EXAMPLE.eu-central-1.elb.amazonaws.com INFO[13:03:33] INFO[13:03:33] Please ensure your DNS settings for "kubermatic.example.com" include the following records: INFO[13:03:33] INFO[13:03:33] kubermatic.example.com. IN CNAME EXAMPLEEXAMPLEEXAMPLEEXAMPLE-EXAMPLE.eu-central-1.elb.amazonaws.com. INFO[13:03:33] *.kubermatic.example.com. IN CNAME EXAMPLEEXAMPLEEXAMPLEEXAMPLE-EXAMPLE.eu-central-1.elb.amazonaws.com. INFO[13:03:33] INFO[13:03:33] 🛬 Installation completed successfully. ✌ ``` The installer will install the following components: * **Nginx-ingress-controller:** Used to access the KKP Dashboard * **Cert-manager:** Responsible for the certificate generation * **Oauth:** Responsible for authentication and authorisation * **Kubermatic Operator chart:** Responsible for deploying Kubermatic pods and components required to make Kubernetes work * **SSD StorageClass:** To store etcd clusters data for every user clusters  ## Setting Up Master Cluster Once all the components are installed, a DNS record must be pointed to the domain name using either the internal or external (LoadBalancer) IP address, depending on your setup. The DNS record will be managed by the cloud service provider, such as Route53, in the AWS environment. You can read more on how to create [DNS records](https://docs.kubermatic.com/kubermatic/v2.16/installation/install_kubermatic/) on AWS cloud provider in the KKP documentation.  You can get the external IP or FQDN using the below command  to connect the hostname with the domain (***kubermatic.example.com***) name: ```bash $ kubectl get services –n nginx-ingress-controller ``` Once the DNS record has been created and pointed to the right domain, a certificate will be automatically generated by "Let’s encrypt for us". Use `kubectl get` command to view the status of the Pods and the generated certificate in the `Kubermatic namespace`. All the Pods in the Kubermatic namespace must be running, while the certificate status output’s `“Ready”` column must be in a `“True”` state if everything works correctly. However, if any of the Pod is not running or the certificate is in a `“False”` state, you can debug it with any but not limited to these steps: * Check the status and details of the Pods and certificates * Check the logs of the Pods * Check the DNS record configuration to be sure that it is pointing to the right domain * Check the domain name * Check the external IP address used for the configuration of the DNS record To check the status of the Pods: ```bash $ kubectl get pods -n kubermatic ``` ```bash NAME READY STATUS RESTARTS AGE kubermatic-api-7db9999755-mznzt 1/1 Running 0 53m kubermatic-api-7db9999755-shdbv 1/1 Running 0 3h56m kubermatic-dashboard-ff7659899-mphkz 1/1 Running 0 21m kubermatic-dashboard-ff7659899-tnl2w 1/1 Running 0 19m kubermatic-master-controller-manager-7d9c95c8dd-n2d6m 1/1 Running 0 3h56m kubermatic-operator-784c5bc74b-ggthx 1/1 Running 0 54m ``` To check the status of the certificate: ```bash $ kubectl get certificates kubermatic-tls -n kubermatic ``` ```bash NAME READY SECRET AGE kubermatic-tls True kubermatic-tls 91m ``` Now that the Pods are running and the certificate is in the “True” state, you can validate that everything works correctly by accessing the KKP Dashboard using the domain name; in this example, `https://kubermatic.example.com/` and login with the static Email and password declared in the ***values.yaml***.   ![Accessing the Kubermatic Kubernetes Platform Dashboard](/static/blog-post_kkp-part3_accessing-kubermatic-dashboard.png) ## Setting Up Seed Cluster Once the master installation is completed, we can now install the Seed cluster. Seed cluster installation requires the installation of the Seed CRD file. This file defines where the user clusters worker’s nodes will be deployed.  The configuration will look like this: ```yaml apiVersion: v1 kind: Secret metadata: name: kubeconfig-cluster-example namespace: kubermatic type: Opaque data: # You can use `base64 -w0 my-kubeconfig-file` to encode the # kubeconfig properly for inserting into this Secret. kubeconfig: <base64 encoded kubeconfig> --- apiVersion: kubermatic.k8s.io/v1 kind: Seed metadata: name: kubermatic namespace: kubermatic spec: # these two fields are only informational country: FR location: Paris # List of datacenters where this seed cluster is allowed to create clusters in # In this example, the user cluster will be deployed in eu-central-1 on AWS. datacenters: aws-eu-central-1a: country: DE location: EU (Frankfurt) spec: aws: images: null region: eu-central-1 enforceAuditLogging: false enforcePodSecurityPolicy: false # reference to the kubeconfig to use when connecting to this seed cluster kubeconfig: name: kubeconfig-cluster-example namespace: kubermatic ``` Use `$ kubectl apply -f seed.yaml` to apply the configuration. Once applied, the Kubermatic operator will start reconciling and install the required components. One of the components will be a nodeport-proxy that is dedicated to Load Balancing (LB) traffic to the right Kubermatic seed cluster. The external IP of the nodeport-proxy will be used to configure the DNS record for the seed cluster. You can access the seed cluster dashboard using the domain name configured in the DNS record and the static Email and password. ## Setting Up User Cluster Once the Seed installation is done, we can move to the user cluster installation. After login into Kubermatic, we can create a user cluster.  Read more on the steps involved in our previous blog post on how to [get started with KKP part 1](/blog/automated-multi-cluster-kubernetes-lifecycle-management/). ## Wrap Up Kubermatic Kubernetes Platform Community Edition is a free tool available under the Apache License v2.0. It can be installed and configured on all major cloud providers such as AWS, Microsoft Azure, GCP, Digital Ocean, OVH, etc. After installing on any of the public clouds, you can further install a monitoring stack to gain metrics and alerting, and a logging stack to collect cluster-wide metrics in a central place.  We can take regular backups of user clusters by snapshotting the etcd of each cluster, and these backups are stored locally by default but can be reconfigured with any compatible S3 storage of AWS. ## Where to Learn More * Visit our [product page](https://www.kubermatic.com/products/kubermatic-kubernetes-platform/) * Watch the demo: [Automate Your Clusters Across Multi-Cloud with Kubermatic Kubernetes Platform](https://www.kubermatic.com/resources/automate-your-clusters-across-multi-cloud-with-kkp/) * Watch the recordings of our webinar series: [Getting Started With Kubermatic Kubernetes Platform](https://www.youtube.com/playlist?list=PLytD1l2uNPnxWZ3I1YLPp8bBIQId9DCU6) --- ## Partnering With Sigmavista to Speed Up Cloud Native Adoption - **URL:** https://www.kubermatic.com/blog/partnering-with-sigmavista-to-speed-up-cloud-native-adoption/ - **Date:** 2026-05-07 - **Description:** Learn more about how we together deliver a comprehensive solution to easily deploy and operate Kubernetes clusters with 100% data storage in Austria. - **Categories:** Company - **Tags:** Announcements - **Authors:** Kristin Wittig Today, we are excited to announce a strategic partnership with sigmavista, an Austrian provider of professional IT services for international corporations, medium-sized enterprises, innovative start-ups and selected partners. . Sigmavista offers private/hybrid cloud solutions and data services to provide IT teams with a simpler, more adaptive infrastructure that is capable of responding to disruptive change. By bringing our long-standing experience with Kubernetes automation at scale to sigmavista’s state-of-the-art data centers, we together deliver a comprehensive solution to easily deploy and operate Kubernetes clusters with 100% data storage in Austria.  Joining forces with sigmavista is an exciting and strategically important next step for us. Having a local partner with a strong footprint in the Austrian region is clearly a meaningful milestone on increasing our visibility outside the German borders. ## About Sigmavista Sigmavista delivers customized solutions that are need-based, flexible, scalable and economical for international corporations, medium-sized enterprises, innovative start-ups and selected partners.Their data centers in Austria are cloud certified and guarantee optimal operational security, global availability and non-stop service for all demands and requirements The service portfolio covers all kind of standard data center solutions as well as the implementation and operation of tailor-made cloud solutions and cloud platforms such as Infrastructure as a Service (IaaS), Platform as a Services (PaaS), Kubernetes as a Service (KaaS) and Backup as a Service (BaaS). ## Where to Learn More * [About sigmavista](https://www.sigmavista.com/) * Demo: [Automate Your Clusters Across Multi-Cloud with Kubermatic Kubernetes Platform](https://www.kubermatic.com/resources/automate-your-clusters-across-multi-cloud-with-kkp/) * [How to Become a Partner at Kubermatic](https://www.kubermatic.com/partners/) --- ## Why Kubermatic? - **URL:** https://www.kubermatic.com/products/kubermatic-kubernetes-platform/why-kubermatic/ - **Date:** 2026-03-17 - **Description:** How Kubermatic Kubernetes Platform is different from PaaS solutions, public cloud providers, and other commercial platforms. # Why Kubermatic? With Kubermatic Kubernetes Platform, Kubermatic provides a complete software solution for teams running containerized workloads across hybrid-cloud, multi-cloud, and edge environments. [Talk to Us](/contact-us/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) []() ## What Is Kubermatic Kubernetes Platform? Kubermatic Kubernetes Platform (KKP) is a Kubernetes management platform designed for the needs of enterprise customers. It addresses the operational challenges of managing Kubernetes at scale while enabling DevOps teams with a self-service developer and operations portal. Unlike other platforms, Kubermatic Kubernetes Platform is truly infrastructure-agnostic and vendor-neutral. ![KKP illustration](/images/why-kubermatic/KKP-illustration.png) ## How Is Kubermatic Kubernetes Platform Different? ### KKP vs. PaaS Often, PaaS comes with an opinionated lifecycle approach and limited provider choice, which restricts your flexibility on preferred tooling and infrastructure. Kubermatic Kubernetes Platform works for any environment and provides you with fully customizable upstream Kubernetes, so you can: - Freely choose your preferred infrastructure set-up (on-prem, hybrid cloud, multi-cloud) - Use any tool that supports Kubernetes as well as any Kubernetes extension, plugin, or integration - Easily integrate your existing landscape and workflows - Embrace new open source technologies as you like ![KKP vs PaaS](/images/why-kubermatic/KKP-vs-PaaS-illustration.png) ### KKP vs. Public Cloud Provider Managed services from cloud providers limit your flexibility and ability to deploy and manage containerized workloads across different infrastructures from one single pane of glass. With Kubermatic Kubernetes Platform, you can: - Avoid vendor lock-in and choose the best-in-class provider for each individual task - Benefit from optimized pricing and migrate workloads as requirements change - Use the same tooling and workflows everywhere from one central interface ![KKP vs Public cloud](/images/why-kubermatic/KKP-vs-Cloud-illustration.png) ### KKP vs. Other Commercial Platforms Thanks to Kubermatic Kubernetes Platform’s unique Kubernetes-in-Kubernetes architecture, teams benefit from unparalleled resilience while minimizing their footprint and infrastructure cost. With KKP, you opt for: - A truly independent and infrastructure-agnostic platform - Competitive pricing with consumption-based subscription - Strong community advocacy and rapid implementation of feature requests ![KKP vs Commercial Platforms](/images/why-kubermatic/KKP-vs-Commercial-Platforms-illustration.png) - [IT Operators](#options-0) - [Developers](#options-1) - [Technology Leaders](#options-2) Most developers do not care a lot about IT infrastructure. They want their environments to be up and running without waiting for their tickets. KKP delivers an intuitive Kubernetes self-service portal so development teams can easily build and deploy their services everywhere while operators keep isolation and control. ![Icon multi-cloud](/images/icons/visuals/item6.svg) ### Automated Multi-cloud Operations Kubermatic Kubernetes Platform automates the deployment and full lifecycle management of hundreds of Kubernetes clusters. Leverage API enabled automation to eliminate manual intervention and repetitive tasks. ![Icon security](/images/icons/badge.svg) ### Enterprise-grade Security and Governance Control access and user rights with built-in Multi-tenancy, role-based access control (RBAC), and cluster authorization and authentication. Consistently deploy securely provisioned clusters with blueprints and presets to keep developers within your company policies. ![Icon single pane of glass](/images/icons/visuals/item1.svg) ### One Single Pane of Glass KKP centralizes your infrastructure management across clusters, clouds, and regions. It also streamlines authentication and access control, user and team management, enterprise security, operational observability, and many other functionalities in one intuitive UI. ![Icon VWs](/images/icons/visuals/item13.svg) ### Run VMs and Containers Side by Side Reduce complexity and leverage Kubernetes to manage your Virtual Machines in a cloud native way. Kubermatic Kubernetes Platform provides native support for KubeVirt so you can operate containerized and legacy workloads from one interface without the need to re-write first. ![Icon Devops](/images/icons/watch.svg) ### Speed-up DevOps KKP supports all Kubernetes conformant tooling to empower your DevOps team to work with the open-source stack they love. Leverage best-in-class ecosystem tooling with native support for Prometheus, Grafana, and Loki for Monitoring and real-time Logging, and the ability to integrate your preferred CI/CD system to deploy Kubernetes clusters directly from it via Service Accounts. Alternatively, your team can use a pre-defined Terraform provider or Ansible playbooks. ![Icon hybrid cloud](/images/icons/multicloud.svg) ### Hybrid and Multi-cloud Support We want to give you the best Kubernetes experience without strings attached. Freely build and re-adapt your preferred infrastructure stack as circumstances change. KKP supports all major cloud providers, including AWS, GCP, Azure, as well as on-prem, bare-metal, and edge environments. Kubermatic Kubernetes Platform provides you with simple self-service Kubernetes so you can easily build and deploy your containerized services everywhere. ![Icon tooling](/images/icons/wrench.svg) ### Freely Choose Your Preferred Tooling KKP is compatible with any tool that supports Kubernetes. This allows you to easily integrate your current landscape as well as incorporate more best-in-class ecosystem tooling. Benefit from the freedom of choice over the entire cloud native landscape and at every stage of your development process. ![Icon talent](/images/icons/star.svg) ### Attract Developer Talent The best developers strive to work with the best tech stack. Adopting popular cloud native and open source technologies like Kubernetes help you win and retain the best talent. And ultimately, the talent of your team defines the quality of your future products and services. ![Icon self-service](/images/icons/visuals/item1.svg) ### Self-service Kubernetes With KKP’s powerful self-service portal, you can easily provision and deploy your environment without waiting for Ops. Thanks to enterprise-grade governance and policies, they keep control while you enjoy the freedom. ![Icon release cycle](/images/icons/rocket.svg) ### Speed up Release Cycles With automated deployment and management across any infrastructure, you streamline your DevOps processes and practices. This enables you to focus on your code and applications, rapidly bringing new releases into production. Cloud native technologies such as containers and Kubernetes deliver the scalability, resilience, and automation organizations need to successfully master digital transformation. Kubermatic Kubernetes Platform removes the complexity of deploying and managing Kubernetes at scale by providing an enterprise-grade management platform that works for any infrastructure. With KKP, your teams are able to embrace cloud native technologies and bring better products to market faster and at a lower cost. ![Icon transformation](/images/icons/transformation.svg) ### DevOps Transformation DevOps is all about processes, tooling, and automation. KKP supports all Kubernetes conformant DevOps tooling, so operators and developers can sync their workflows and collaborate more closely. By automating the maintenance of cloud native infrastructure, DevOps teams are able to focus on innovation, not keeping things up and running. ![Icon ROI](/images/icons/cash.svg) ### Kubernetes ROI Containerized applications and Kubernetes bring about higher density, optimized capacity utilization, and less downtime. This yields considerable savings in infrastructure and operations cost for any organization. With our flexible and consumption-based subscription model, you only pay the capacity you actually need. ![Icon productivitiy](/images/icons/visuals/item9.svg) ### Increase Developer Productivity & Innovation KKP equips developers with an intuitive self-service portal to provision and deploy the environment they need without waiting for operations. This increases developer productivity and speeds up development cycles while at the same time helping organizations attract the best talent in the market. ![Icon business models](/images/icons/shaking-hands.svg) ### Empower Future Business Models Thanks to their scalability, cloud native technologies are a catalyst for 5G, Big Data, AI, and ML use cases. Kubermatic Kubernetes Platform provides for complex deployment scenarios across any infrastructure, including the edge. This makes KKP the ideal solution for enterprises exploring new business models based on these powerful technologies. ### Why Teams Love Working With Kubermatic Kubernetes Platform ### One of the Best Kubernetes Management Tools ![double ticks](/images/gradient-double-ticks.svg) KKP has been helping my team and me to complete most of our working within deadlines and focus more on serving customers. Imoh E., Cloud Engineer ![Imoh E., Cloud Engineer](/images/reviewers/imoh-e.jpg) ### Great Management Interface ![double ticks](/images/gradient-double-ticks.svg) I love the management interface, it's very intuitive and very easy to use. Jim O., Cloud Engineer ![Jim O., Cloud Engineer](/images/reviewers/jim-o.jpg) ### Great Product for Rookies ![double ticks](/images/gradient-double-ticks.svg) The ease of use for rookies entering K8s. Given the magic of K8s albeit the complexity, KKP simplifies the K8s management. Akshay P., Data Engineer ![Akshay P., Data Engineer](/images/reviewers/akshay-p.jpg) ### Very Easy to Use ![double ticks](/images/gradient-double-ticks.svg) KKP makes my workflow with Kubernetes containers so easy and handles the application in multi-cloud environments with ease. Abhinavan R., Software Developer ![Abhinavan R., Software Developer](/images/reviewers/abhinavan-r.jpg) ### Best Access Control by Kubermatic Kubernetes Platform ![double ticks](/images/gradient-double-ticks.svg) It has helped us switch over digital operation by fully automating our cloud operations. DevOps team are centrally managing all VMs, also they look over our workloads like hybrid clouds and multi-cloud. Yatharth G., VP ![Yatharth G., VP](/images/reviewers/yatharth-g.jpg) []() ## Technology & Ecosystem Integrations Kubermatic Kubernetes Platform (KKP) provides the best options in open source cloud native tooling so your infrastructure can support your business scale as fast as you desire. ![](/static/gear-icon.svg) ### Operating System ![CentOS](/static/Centos-logo.svg) ![Ubuntu](/static/ubuntu-black-orange.svg) ![RedHat](/static/RedHat-logo.svg) ![Flatcar](/static/flatcar-logo.svg) ![Suse](/static/SUSE-linux-logo.svg) ![](/static/networking-icon.svg) ### Networking & Observability ![Cilium](/static/cilium-logo.svg) ![Canal](/static/canal-logo.png) ![Hubble](/static/hubble-logo.png) ![](/static/users-icon.svg) ### Identity Management ![Dex](/static/dex-logo.svg) ![LDAP](/static/ldap-logo.png) ![Active Directory](/static/active-directory-logo.svg) ![](/static/shield-icon.svg) ### Security ![OPA](/static/opa-logo.svg) ![OAuth2-Proxy](/static/oauth2-proxy-logo.svg) ![](/images/icons/visuals/item1.svg) ### External Cluster Management ![GKE](/static/gke-logo.svg) ![EKS](/static/eks-logo.svg) ![AKS](/static/aks-logo.svg) ![](/static/chart-icon.svg) ### Monitoring & Logging ![Minio](/static/min-io-logo.svg) ![Grafana](/static/grafana-logo.svg) ![Prometheus](/static/prometheus-logo.svg) ![Loki](/static/loki-logo.svg) ![Cortex](/static/cortex-logo.svg) ![](/static/circle-flow-icon.svg) ### SRE Workflow ![Github](/static/github-logo.svg) ![Gitops](/static/git-logo.svg) ![Harbor](/static/harbor-logo.svg) ![Gitlab](/static/gitlab-logo.svg) ![flux](/static/flux-logo.svg) ![Argo](/static/argo-logo.svg) ![](/static/flow-chart-icon.svg) ### IaaS Operator ![AWS](/images/logos/aws-logo.svg) ![Google Cloud](/static/google-cloud-logo.svg) ![Azure](/images/logos/azure-logo.svg) ![OpenStack](/static/openstack-logo.svg) ![VMware vSphere](/static/vsphere-logo.png) ![Open Telekom Cloud](/images/logos/open-telekom-cloud-logo.png) ![DigitalOcean](/images/logos/digitalocean-logo.svg) ![Hetzner Cloud](/static/hetzner-logo.svg) ![Alibaba Cloud](/static/alibaba-cloud-logo.svg) ![Equinix Metal](/static/equinix-metal-logo.svg) ![Kubeadm](/static/kubeadm-logo.svg) ![Nutanix](/static/nutanix-logo.svg) ![Arm](/static/arm-logo.svg) --- ## Kubermatic Office Hours February 2021 - **URL:** https://www.kubermatic.com/resources/office-hours/ - **Date:** 2022-12-01 - **Description:** Learn more about Kubermatic Kubernetes Platform Release 2.16 and how to install EKS-D with KubeOne. # Office Hours ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch Our February Office Hours In our February 2021 Office Hours, our technical experts covered the following topics: - General Kubernetes update - Our new Kubermatic Kubernetes Platform release 2.16 - Installing EKS-D with KubeOne ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Kubernetes Empowers Your DevOps Organization - **URL:** https://www.kubermatic.com/resources/empower-your-devops-organization-with-kubernetes/ - **Date:** 2022-12-01 - **Description:** Learn more about how to fully automate your Kubernetes operations with Kubermatic Kubernetes Platform. # Empower Your DevOps Organization With Kubernetes ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Watch Our Partner Webinar With Darumatic to Learn About DevOps Best Practices Over the past years, the DevOps movement has received a large amount of attention, and rightly so; practices under this term have been evidenced to improve the time to market, the overall software quality and even make teams happier. But how exactly? And what does Kubernetes and cloud native technologies have to do with that? We’ll walk through **best practices of the DevOps approach,** explain why Kubernetes further promotes this movement and demonstrate how our **open source Kubermatic Kubernetes Platform can empower your DevOps organization** by fully automating your Kubernetes operations. Topics covered: - Introduction to DevOps - How KKP provides full lifecycle management for thousands of Kubernetes clusters - KKP demo ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## The Smallest Kubernetes Cluster: Scaling Down to the Edge - **URL:** https://www.kubermatic.com/blog/the-smallest-kubernetes-cluster-scaling-down-to-the-edge/ - **Date:** 2026-05-07 - **Description:** Learn more about how to unlock Kubernetes for Edge Computing With Kubermatic Kubernetes Platform. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Sascha Haase Edge computing is creating a new internet. In an age where consumers and businesses demand the shortest possible delay between asking a question and getting an answer, edge computing is the only way to reduce the time it takes to provide this insight. Edge computing shrinks the gap by lowering latency, dealing with data even when there is insufficient bandwidth, decreasing costs, and handling data sovereignty and compliance.  While centralized cloud computing will persist, the radically different way in which we can create and act upon data at the edge of the network will - and already does - create novel markets. **By 2024, the global edge computing market is expected to be worth over $9.0 billion (USD) with a compound annual growth rate of 30%.**  The key question is: what operational models and technologies will be able to effectively unlock this potential? ## Kubernetes Unlocks Edge Computing As a new field, edge computing is currently a blank slate with best practices still only emerging.  Even without any standards in the field, many companies are starting to turn towards Kubernetes for their edge computing requirements.  Kubernetes has already taken enterprise IT by storm with 86% of companies using Kubernetes according to the latest Cloud Native Computing Foundation (CNCF) survey. While Kubernetes was born in the cloud, the benefits it provides also extend into the quickly emerging edge computing market.  With hardware and software spread across hundreds or thousands of locations, the only feasible way to manage these distributed systems is through standardization and automation enabled by cloud native technologies.  However, if companies truly want to use Kubernetes to manage their edge computing deployments, they must carefully consider the other challenges that the edge presents.  The top concern is resource constraints. Kubernetes was built in the cloud with almost infinite scaling capabilities. In contrast, edge computing usually has a very finite set of resources. The actual limitations can vary considerably from a few servers to a few hundred MBs of memory as we move from the regional edge to the device edge. However, they all share the restriction that every bit of overhead takes away from running actual applications.  With this in mind, the question now becomes: how can we reduce the footprint of Kubernetes to leave more space for customer applications? ## The Smallest Kubernetes Cluster A Kubernetes cluster consists of the control plane and the worker nodes. To shrink this footprint, some projects have tried to strip nonessential elements out of Kubernetes to create a slimmed down version.  However, this creates a fork of Kubernetes that needs to be maintained and managed independently from the rest of your Kubernetes stack. Instead of trying to cut things out, we can reimage how we architect our clusters to take into account how edge computing is architected. ![Kubernetes Edge Architecture](/static/the-smallest-kubernetes-cluster_scaling-down-to-the-edge_kubernetes-edge-architecture.jpg) Edge computing is not a precise place or type of device, but more a continuum of locations away from centralized cloud computing. Moving further away from the cloud usually means devices and bandwidth are more constrained.  However, each level of edge computing is usually connected back to, and to some extent controlled by, at least one of the levels above it. The edge is where the workload runs, but it still connects back to more centralized computing for higher level functions.   We can actually think of Kubernetes in the same way, as two independent parts: one centralized for control and one distributed for computing. The worker nodes run the applications while the control plane merely does the installation and maintenance of the workloads running in the cluster.  For a workload to just function, the control plane is not needed because it only does life cycle management. If the worker node loses connection to the control plane, the workloads can continue to function and run, they just will not be able to be updated.  With this in mind, we can think of the functional unit of our Kubernetes cluster as just the worker nodes with a kubelet. The centralized management of the control plane is not needed the whole time for the workload to be in working order.  With this new concept of what a Kubernetes cluster really is, we can start to re-think how we build Kubernetes clusters for environments with limited resources. The worker nodes can be run on constrained devices while the control plane can be run in a more centralized location with additional resources, whether that be an on-premise data center or even extending back to the public cloud. This allows operations teams to run Kubernetes on edge computing without the need to make modifications or maintain another technology stack, all while minimizing overhead.  ![Kubernetes Clusters With the Control Plane Separated from the Worker Nodes](/static/the-smallest-kubernetes-cluster_scaling-down-to-the-edge_kubernetes-clusters-with-the-control-plane-separated.png) ## Cluster Management Chaos The multi-billion dollar edge computing market will be composed of trillions of devices running millions of clusters. Thus, it begs the question of how to manage them and keep the control plane and worker nodes in sync even when they are running in separate locations.  We built the open source [Kubermatic Kubernetes Platform](https://www.kubermatic.com/products/kubermatic-kubernetes-platform/) with this use case in mind. Its Kubernetes in Kubernetes architecture already separates the control plane from the worker nodes and manages them independently. The control plane is run as a set of containers within another cluster that can be running in a less resource-constrained environment, while the worker nodes only need to run a kubelet, radically reducing the footprint of the Kubernetes cluster on the edge. In addition, Kubermatic Kubernetes Platform automates the cluster life cycle management which is especially important for edge computing business and operational models. ## How to Try It Out Kubermatic Kubernetes Platform allows users to separate the control plane and the worker nodes to run the smallest “Kubernetes clusters” for edge computing and constrained devices.  You can try it out for yourself or contribute to the project on [GitHub](https://github.com/kubermatic/kubermatic). --- ## Volume and volumeMounts: An Introduction - **URL:** https://www.kubermatic.com/blog/keeping-the-state-of-apps-1-introduction-to-volume-and-volumemounts/ - **Date:** 2026-05-07 - **Description:** Learn how to provide persistent storage in the form of different volumes to the Pods. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Seyi Ewegbemi In this part of our Kubernetes 101 series, we will bring persistence into play. You will learn how to provide persistent storage in the form of different volumes to the Pods. This allows containers within the Pods or other distributed instances in the cluster to have access to the same data by mounting the created volume inside a container. The topics below will be covered as well as hands-on practice to show you a real-time scenario on how these components work: * Definitions of  Volumes and volumeMount  * What types of Volumes are available? * How to use simple Volumes and volumeMount inside a Pod  * Hands-on practice  ## Kubernetes Volumes and volumeMounts A Volume in Kubernetes represents a directory with data that is accessible across multiple containers in a Pod. The container data in a Pod is deleted or lost when a container crashes or restarts, but when you use a volume, the new container can pick up the data at the state before the container crashes. The volume outlives the containers in a Pod and can be consumed by any number of containers within that Pod.  A **volume** usage entails the declaration of the volume in a Pod by specifying a **“volumes”** property under the **spec (spec.volumes)** field in a Pod manifest file, followed by the volume in an array format. The configuration will look like this: ```yaml spec: volumes: - name: xyz ``` A **volumeMount**, on the other hand, entails mounting of the declared volume into a container in the same Pod. A **“volumeMounts”** property (spec.container.volumeMounts), as well as the “name” property which is the volume name to be mounted and the mountPath field where the volume will be mounted, are declared in the container in a Pod. The configuration will look like this: ```yaml spec: containers: - name: my-app image: nginx volumeMounts: - name: xyz mountPath: /app/config ``` Volume and volumeMounts go hand in hand. You can not create a volume without mounting it or mount a volume that has not been created.  Below is a configuration example of a volume declaration in a Pod and mounting of the declared volume in a container: ```yaml spec: containers: - name: my-app image: nginx volumeMounts: - name: xyz mountPath: /app/config volumes: - name: xyz ``` NOTE: It is vital that the name of the volume to be mounted in the container under the **volumeMounts.name** property is the same as the name of the volume.  ## Types of Volumes Currently, there are different volume types supported by [Kubernetes](https://kubernetes.io/docs/concepts/storage/volumes/). We will walk you through some of these types including hand-on practice to give you a deeper knowledge of the functionalities. There are volume types that require external configuration like awsElasticBlockStore, azureDisk etc. which might involve billing or payment. We will exclude these from our hands-on practice but focus on others like emptyDir, hostPath, secret, configMap etc.  More on volume types can be found in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/storage/volumes/) on volume.  ## Volume Types Category Volume types are classified into two categories: 1. Ephemeral: This is the category with the same lifetime as the Pod lifecycle but persists beyond container restart. It is a fast volume solution but not durable, thus, should be used for temporary data or applications that do not require data persistency. The volume types under this category are emptyDir, configMap, secret etc. 2. Durable: These are volume types that outlive the Pod lifecycle. The lifetime is independent on the Pod lifecycle but persists across both container and Pod restarts. Data is preserved in this category when Pod crashes or is deleted. The volume types under this category are: hostPath, persistentVolumeClaim, awsElasticBlockStore, azureDisk, gcePersistentDisk etc.  ## EmptyDir Volume Type An emptyDir volume is a volume type that is first created when a Pod is assigned to a Node. Its lifespan is dependent on the lifecycle of the Pod on that Node but recreates when the containers crash or restart. When a Pod dies, crashes, or is removed from a Node, the data in the emptyDir volume is deleted and lost. This type of volume is suitable for temporary data storage. ### How to Create an emptyDir Volume An emptyDir volume type is created by first creating a volume and then declaring the volume type name as a field in the Pod manifest file under the volume property section with empty curly braces{} as its value. The example will look like this: ```yaml volumeMounts: - mountPath: /cache name: my-volume volumes: - name: my-volume emptyDir: {} ``` Now that you have seen what volume and volumeMount entail and their functionalities theoretically, it is now time to put this into practice by following the steps below on how to create a volume with emptyDir as the volume type.  It is essential to have a basic knowledge of Pods/Deployments to follow this exercise. You can check our previous blog posts on [Pods](https://www.kubermatic.com/blog/introduction-to-pods/) and [Deployments](https://www.kubermatic.com/blog/introduction-to-kubernetes-replicasets/) to familiarise yourself with how to work with them. You also need a running Kubernetes cluster and the kubectl command-line tool must be configured to work with the cluster. You can easily create a Kubernetes cluster on any environment with [KubeOne](https://github.com/kubermatic/kubeone#getting-started). Check our [Getting Started](https://github.com/kubermatic/kubeone#getting-started) guide for instructions. Alternatively, you can simply use the [Kubernetes playground](https://labs.play-with-k8s.com/) for practising purposes.  The steps below will walk you through how to create a Pod that uses emptyDir volume type. **Step 1:** Create a Pod with the below manifest file: ```yaml apiVersion: v1 kind: Pod metadata: name: myapp spec: containers: - name: my-app image: nginx ports: - containerPort: 8080 imagePullPolicy: Always volumeMounts: - name: my-volume mountPath: /app volumes: - name: my-volume emptyDir: {} ``` The above manifest file is described as follow: ```bash apiVersion→ ## Deployment object apiVersion. Every object in Kubernetes has its apiVersion with values which includes v1, apps/v1, batch/v1 depending on the object. kind → ## This field declares the object and the value must be in sentence case. metadata.name 🡪 ## The name of the object to be created is declared in this field. spec.containers.name 🡪 ## This field declares the name of the container image. spec.containers.image 🡪 ## The container image for the application is declared in this field. volumes.name → ## The name of the volume is declared in this field. volumes.emptyDir → ## The volume type is specified in this field. volumeMounts.name → ## The declared volume is injected into the container in this field which is why the declaration is under the container specification. The name must be the same as the name of the volumes. volumeMounts.mountPath → The path where the volume will be mounted. ``` **Step 2:** Create the Pod using kubectl create command: ```bash $ kubectl create -f emptyDir.yaml pod/myapp created ``` **Step 3:** Check the status of the Pod to see if it is running: ```bash $ kubectl get pod NAME READY STATUS RESTARTS AGE myapp 1/1 Running 0 15s ``` **Step 4:** Check the Pod description for more information about the volume in the Pod: ```bash $ kubectl describe pod myapp Name: myapp Namespace: default Priority: 0 Node: node01/172.17.0.11 Start Time: Fri, 09 Oct 2020 19:25:37 +0000 Labels: <none> Annotations: <none> Status: Running IP: 10.244.1.7 IPs: IP: 10.244.1.7 Containers: my-app: Container ID: docker://f7fe0c11eef32b6c619a619354895458b7d7a7602f5d09aea03fec0c90efa082 Image: nginx Image ID: docker-pullable://nginx@sha256:fc66cdef5ca33809823182c9c5d72ea86fd2cef7713cf3363e1a0b12a5d77500 Port: 8080/TCP Host Port: 0/TCP State: Running Started: Fri, 09 Oct 2020 19:25:40 +0000 Ready: True Restart Count: 0 Environment: <none> Mounts: /app from my-volume (rw) /var/run/secrets/kubernetes.io/serviceaccount from default-token-z8p4x (ro) Volumes: my-volume: Type: EmptyDir (a temporary directory that shares a pod's lifetime) ``` **Step 5:** Exec into the Pod and perform some basic commands: ```bash $ kubectl exec -it myapp -- bin/bash root@myapp:/# ls ## Check to see if the directory is available app bin boot dev docker-entrypoint.d ``` **Step 6:** Check the volume in the directory for existing data. In this case, it should be empty. ```bash $ root@myapp:/# ls app/ $ root@myapp:/# ``` **Step 7:** Create a file and write some data into it: ```bash $ root@myapp:/# echo I love Kubermatic > app/new-file ``` **Step 8:** Check to see if the data is stored: ```bash $ root@myapp:/# ls app/ new-file ``` Now that you can see that it is stored, display the content of the data using the below command: ```bash $ cat app/new-file I love Kubermatic ``` **Step 9:** Exit the Pod and perform a clean up by deleting the Pod using kubectl delete command: ```bash $ kubectl delete pod myapp pod "myapp" deleted ``` ## HostPath Volume Type hostPath volume type is a durable volume type that mounts a directory from the host Node’s filesystem into a Pod. The file in the volume remains intact even if the Pod crashes, is terminated or is deleted. It is important that the directory and the Pod are created or scheduled on the same Node.  The below manifest represents a hostPath configuration inside a Pod: ```yaml volumes: - name: hostpath-volume # The name of the volume hostPath: path: /data # directory location on host ``` ### How to Create and use a hostPath Volume in a Pod You can create a hostPath volume and just like the emptyDir volume type. However, the volume type name, hostPath, will replace the emptyDir in the Pod manifest file. You will also declare a path property which is the directory location on the host and a child of hostPath property. The complete configuration will look like this: ```yaml apiVersion: v1 kind: Pod metadata: name: myapp spec: containers: - name: my-app image: nginx ports: - containerPort: 8080 volumeMounts: - name: my-volume mountPath: /app volumes: - name: my-volume hostPath: path: /mnt/vpath ``` Now that the manifest file is ready, the below steps will guide you on how to create a hostPath volume and mount it into a Pod; after that, we will test the functionalities. **Step 1:** Create a Pod with the manifest file above: ```bash $ kubectl create -f hostpath-volume.yaml pod/myapp created ``` **Step 2:** Check the status of the Pod using kubectl get command: ```bash $kubectl get pod NAME READY STATUS RESTARTS AGE myapp 1/1 Running 0 10m ``` **Step 3:** Exec into the Pod and create a file in the directory: ```bash $kubectl exec -it myapp -- /bin/bash root@myapp:/# ``` **Step 4:** Change to the /app directory: ```bash root@myapp:/# cd /app ## Where /app is the mountPath value from the YAML manifest file. ``` **Step 5:** Create a file using echo command and store some data in the file: ```bash root@myapp:/app# echo "I love Kubermatic" > file.txt ``` **Step 6:** Check to see if the data is created and stored in the file: ```bash root@myapp:/app# ls file.txt root@myapp:/app# cat file.txt I love Kubermatic Exit the Pod. root@myapp:/app# exit exit ``` Now, ssh into the Node to check if the data created in the /app directory in the Pod can be found in the /mnt/vpath in the Node. **Step 7:** ```bash $ ssh ubuntu@x.xx.xxx.xxx ubuntu@x.xx.xxx.xxx:~$ ``` Here, ubuntu is the username while **_`x.xx.xxx.xxx`_** is the hostname i.e (internal or external IP address). Your username and hostname might differ depending on the OS and cloud provider you used when provisioning your cluster.  **Step 8:** Change to the /mnt/vpath directory, which is the value of the hostpath path in the YAML manifest file. ```bash ubuntu@x.xx.xxx.xxx:~$ cd /mnt/vpath ubuntu@x.xx.xxx.xxx:/mnt/vpath$ ``` **Step 9:** Check to confirm if the file and data created in the Pod above are available in the directory: ```bash ubuntu@x.xx.xxx.xxx:/mnt/vpath$ ls file.txt ubuntu@x.xx.xxx.xxx:/mnt/vpath$ cat file.txt I love Kubermatic ``` Now, create another file and store some data in the file inside the Node. Exit the Node and login into the Pod using kubectl exec. Then perform Step 6 once again to view the file and data created in the Node directly in the Pod and exit. **NOTE:** The Pod must be running in the same Node. ## Checking the Persistent State of a hostPath Volume One of the advantages of hostPath volume over EmptyDir is the ability to outlive the Pod lifecycle. We want to show you the practical steps of this scenario by deleting the Pod and then ssh into the Node once again to check the file and the data.   **Step 1:** Delete the Pod using kubectl delete command: ```bash $ kubectl delete pod myapp pod "myapp" deleted ``` **Step 2:** Check the status of the Pod: ```bash $ kubectl get pod No resources found in default namespace. ``` **Step 3:** Now that the Pod has been deleted, ssh into the Node and perform step 8 and 9. ```bash ubuntu@x.xx.xxx.xxx:~$ cd /mnt/vpath ubuntu@x.xx.xxx.xxx:/mnt/vpath$ ubuntu@x.xx.xxx.xxx:/mnt/vpath$ ls file.txt ubuntu@x.xx.xxx.xxx:/mnt/vpath$ cat file.txt I love Kubermatic ``` You can see that the data stored in a file which was initially created in a Pod remains intact and can be accessed through the Node even when the Pod has been deleted. This affirms the ability of hostPath volume type to outlive the lifecycle of a Pod. **Summary** Now that you have seen and practiced how to create a volume using emptyDir and hostPath volume types, and mount the volume into a container in a Pod , we are going to look at  Secret and ConfigMap which are ephemeral volume types in our next blog post. What is a Kubernetes Secret and configMap? What are their similarities, differences and functionalities? These and many more questions will be our focus in the next parts of this series.  We’d love to hear from you! Please [contact us](mailto:marketing@kubermatic.com) with any thoughts or questions you might have about volumes. ## Learn More * Learn more about the concepts of  [Kubernetes volume and types here](https://kubernetes.io/docs/concepts/storage/volumes/). * Read more on [hostPath](https://kubernetes.io/docs/concepts/storage/volumes/#hostpath) volume type [here.](https://kubernetes.io/docs/concepts/storage/volumes/#hostpath) * Read more on [emptyDir](https://unofficial-kubernetes.readthedocs.io/en/latest/concepts/storage/volumes/#emptydir) volume type [here.](https://unofficial-kubernetes.readthedocs.io/en/latest/concepts/storage/volumes/#emptydir) * More on volume types can be found [here](https://unofficial-kubernetes.readthedocs.io/en/latest/concepts/storage/volumes/#emptydir). --- ## Kubermatic Kubernetes Platform 2.16 Is Here! - **URL:** https://www.kubermatic.com/blog/kubermatic-kubernetes-platform-2-16-is-here/ - **Date:** 2026-05-07 - **Description:** Learn more about the OPA support and how our Kubeflow integration empowers truly cloud native Machine Learning. - **Categories:** Products - **Tags:** KKP - **Authors:** Kristin Wittig Here we go, our first release of the year is out! With Kubermatic Kubernetes Platform (KKP) 2.16, we now support the Open Policy Agent for improved policy control and have added dynamic data centers and other expanded GitOps capabilities. On top of that, with Machine Learning being one of the hottest topics of the decade, we are committed to continuously enhance KKP with convenient ML Add-Ons to give data scientists the freedom to always leverage the best cloud for their needs. With KKP 2.16, we are proud to unveil a preview of a Kubeflow integration to provide for truly cloud native Machine Learning.  Read on for these and other improvements our team has been busy with over the past months. ## Enterprise-Grade Policy Compliance With Open Policy Agent  Keeping your entire technology stack compliant with your organization’s policies can be an operational nightmare. KKP 2.16 introduces an out-of-the-box integration of the Open Policy Agent (OPA) that enables you to centrally manage and enforce policies in microservices, Kubernetes, CI/CD pipelines, API gateways, and more. OPA is an open source project that provides a high-level declarative language that lets you specify policy as code and APIs to offload policy decision-making to your software.  So far, users can access OPA via the Kubermatic API. We will add a fully-fledged UI integration with one of the upcoming patch releases. Stay tuned! ## Expanded GitOp Capabilities With Dynamic Data Centers and Other Enhanced Admin Configurations With KKP 2.16, platform administrators are now able to dynamically configure the data centers they want to use, so they can easily add new ones on the fly.  ![Dynamic Data Centers](/static/announcing-kubermatic-kubernetes-platform-2.16_dynamic-datacenters_sharpened.png) Moreover, the release includes new Preset Management functionalities that enable administrators to configure dev, pre-production, and production environments. Users can then simply choose the environment they need when creating a new Kubernetes cluster, and it will automatically have every configuration attached. ![Preset Management Functionalities](/static/announcing-kubermatic-kubernetes-platform-2.16_presets_sharpened.png) Finally, we introduce the possibility to centrally configure your consumption, providing you with an easy way to manage and control your infrastructure cost.  All configuration can be adjusted in the KKP UI or via Infrastructure-as-Code, helping you to pursue and develop your GitOps approach.   ## Machine Learning the Cloud Native Way Machine learning and Kubernetes are great matches and Kubeflow is a great platform for bringing the two worlds together: The open source project makes deployments of ML workflows on Kubernetes simple, portable, and scalable. With our preview, KKP operators can now easily roll out the Kubeflow platform on top of KKP. This integration gives your data scientists the possibility to leverage the power of every cloud available and generate their results most efficiently. (Of course, we are curious to hear your feedback. Please feel free to share your thoughts and ideas with us: [product@kubermatic.com](mailto:product@kubermatic.com))  ![Kubeflow Addon](/static/announcing-kubermatic-kubernetes-platform-2.16_kubeflow-addon.png) ## Benefit From Optimized Infrastructure With ARM Support  ARM-powered data centers and edge scenarios are enjoying increasing popularity for their system optimization and cost reduction potential. Since we are dedicated to providing you with the broadest possible infrastructure, KKP 2.16 introduces ARM support. Thanks to this out-of-the-box integration, KKP users can now effortlessly deploy and manage their ARM-based clusters from the central KKP interface.   ## Deprecate and Remove CoreOS  CoreOS officially reached end-of-life on May 26, 2020. With the 2.16 release, we will stop supporting any cluster using CoreOS. In this [blog post](https://www.kubermatic.com/blog/support-for-coreos-container-linux-has-ended/), we explain how you can migrate your clusters to not run into major security liability from defective clusters. (If you liked CoreOS, we are sure you will like Flatcar Container Linux by the awesome Kinfolk folks as well. Of course, KKP comes with Flatcar support). At Kubermatic, we are dedicated to continuously innovate with the cloud native community. We are looking forward to our next release in a few months and hope you are, too. Stay tuned – there is some cool stuff coming up. In the meantime, feel free to [get in touch](https://www.kubermatic.com/company/community/#discussions) via Github, Slack, or our Forum.  ## Learn More * Take a closer look at our [Kubeflow Addon](https://docs.kubermatic.com/kubermatic/v2.16/advanced/addons/kubeflow/) * Check out the entire [Changelog](https://github.com/kubermatic/kubermatic/blob/master/CHANGELOG.md) * Join our live [Office Hours](https://youtu.be/_BbHHd-ecOQ) on February 17 * More information on [CoreOS end-of-life](https://coreos.com/os/eol/) --- ## Support for CoreOS Container Linux Has Ended - **URL:** https://www.kubermatic.com/blog/support-for-coreos-container-linux-has-ended/ - **Date:** 2026-05-07 - **Description:** Learn how to migrate your clusters to be able to upgrade to Kubermatic Kubernetes Platform 2.16. - **Categories:** Products - **Tags:** KKP - **Authors:** Marcin Franczyk Since May 2020 CoreOS Container Linux is end of life and no longer receives updates. With the upcoming Kubermatic Kubernetes Platform (KKP) 2.16 release, we will no longer support CoreOS Container Linux. In case you still have CoreOS clusters running, you risk to encounter major security liability from defective clusters. Please read this blog post to learn how to migrate your clusters to be able to upgrade to v2.16. ## How Do I Check If I Have Running CoreOS Nodes? You can check the operating system from the KKP dashboard (machine deployments list) or over kubectl commands, for instance: `kubectl get machines -nkube-system` or `kubectl get nodes -owide`. ## I Have Running CoreOS Nodes And I Want to Upgrade to v2.16 In The Future. What Should I Do? You should create another machine deployment with a demanded operating system (like Flatcar or else) and delete (or scale down) the old CoreOS machine deployments. Remember to wait for new machines to come up. NOTE: To avoid double cluster size, we recommend you to scale up a new machine deployment and scale down the CoreOS deployments one by one. Remove old deployments afterward. ## Will My Pods Be Evicted to Other Nodes? Yes, Kubermatic supports pod’s eviction. With the new deployment, you can then migrate the containers to the newly created machines and check if the application behaves like intended.  Additionally, it is a good idea to consider a pod disruption budget for each application you want to transfer to other nodes. Example PDB resource: ```yaml apiVersion: policy/v1beta1 kind: PodDisruptionBudget metadata: name: example-pdb spec: minAvailable: 2 selector: matchLabels: app: nginx ``` Find more information [here](https://kubernetes.io/docs/tasks/run-application/configure-pdb/). ## Do I Have to Rely on the Kubermatic Eviction Mechanism? No, you can drain and cordon the nodes yourself. Remember to delete the CoreOS machine deployment afterward. Find more information [here](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/). ## Eviction Stuck – What Should I Do? When you choose to rely on the Kubermatic eviction mechanism, we assume that the eviction is blocked by misconfiguration or a misbehaving kubelet and/or controller-runtime. If the deletion got triggered a few hours ago (by default, 2 hours), the mechanism would skip the eviction, and node deletion will continue. This means that the pod disruption budget would not be respected. If you drain and cordon the nodes yourself, please find more information [here](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/#stuck-evictions). In case you have questions regarding the CoreOS EOL or trouble migrating from CoreOS, please feel free [to reach out to us](https://www.kubermatic.com/company/community/#discussions). ## Where to Learn More * You will find more information on CoreOS EOL [here](https://coreos.com/os/eol/) * Find [KKP on Github](https://github.com/kubermatic/kubermatic) to get all the updates on v2.16 soonish --- ## Kubernetes on Hetzner with Kubermatic KubeOne in 2021 - **URL:** https://www.kubermatic.com/blog/kubernetes-on-hetzner-with-kubermatic-kubeone-in-2021/ - **Date:** 2026-05-07 - **Description:** Learn more about how to bootstrap a Kubernetes Cluster on Hetzner with KubeOne. - **Categories:** Products, Community - **Tags:** KubeOne, Open Source Projects - **Authors:** Christian Rebischke **Guest post by Christian Rebischke, SRE at avency GmbH** *Christian has bootstrapped a Kubernetes cluster on Hetzner cloud with our open source cluster lifecycle management tool Kubermatic KubeOne. We are happy to have him sharing his experience on our blog.* Hello and welcome to my little Kubernetes on Hetzner tutorial for the first half of 2021. This tutorial will help you bootstrapping a Kubernetes Cluster on Hetzner with [KubeOne](https://github.com/kubermatic/kubeone). I am writing this small tutorial, because I had some trouble to bootstrap a cluster on Hetzner with KubeOne. But first of all let us dive into the question why we even need KubeOne and how KubeOne helps. KubeOne is a small wrapper around [kubeadm](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/). Kubeadm is **the** official tool for installing Kubernetes on VMs or bare-metal nodes, but it has one major disadvantage: It is very toilsome. KubeOne tries to solve this with providing you a wrapper around Kubeadm and various other provisioning tools like [Terraform](https://www.terraform.io/). Terraform lets you manage your infrastructure as code. The advantage is that you can easily destroy, deploy or enhance your infrastructure via a few config file changes. You may ask yourself why you even need this tutorial. There is already at [least one tutorial](https://community.hetzner.com/tutorials/install-kubernetes-cluster) that guides you through the process of setting up a Kubernetes cluster on Hetzner. This is correct, but I felt it is unnecessary complicated, takes too much manual steps and is not really automatable (although there are solutions like [kubespray](https://github.com/kubernetes-sigs/kubespray) that intend to solve this). I hope you will give this tutorial a chance and I promise that you will not regret it. You will definitely learn something from it. For the beginning you need the following ingredients for mixing your first Kubernetes cluster with Hetzner flavor: * A Hetzner Cloud account * [KubeOne](https://github.com/kubermatic/kubeone) * [Terraform](https://www.terraform.io/) * Basic understanding of Kubernetes and Linux The first and the last is something I assume that you already have. Installing KubeOne and Terraform should be easy on Arch Linux. You can just install it from the repositories (I am maintaining them hrhr): ```bash $ pacman -Syu terraform kubeone ``` Furthermore I suggest that you clone the KubeOne repository. It has some great examples for Hetzner and gives you a first insight on what you can do with it and what not: ```bash $ git clone https://github.com/kubermatic/kubeone ``` If you are in the Hetzner Cloud console I suggest that you create a new project for playing around (Just in case we screw things up). For this new project you need a new API token. Again, I assume that you know how to do this. The token needs read **and** write permissions. First we move in the freshly cloned repository and investigate the files in it: ```bash $ cd kubeone/examples/terraform/hetzner $ ls .rw-r--r-- 2.6k chris 17 Dec 2020 main.tf .rw-r--r-- 2.4k chris 17 Dec 2020 output.tf .rw-r--r-- 1.8k chris 17 Dec 2020 README.md .rw-r--r-- 1.9k chris 25 Jan 22:01 variables.tf .rw-r--r-- 131 chris 17 Dec 2020 versions.tf ``` The `README.md` file gives us a brief explanation about inputs and outputs and gives us hints about loadbalancers. The `versions.tf` file tells us the required Terraform version and the required providers. In our case the cloud provider is hcloud. The `variables.tf` file defines all variables for our new cluster infrastructure. The `output.tf` file defines the output of Terraform. This will get important later, because we will use the output as direct input for KubeOne. The `main.tf` file hides the core logic behind all of this. The `main.tf` file is reponsible for bootstrapping the infrastructure. In this file we see networks, ssh keys, loadbalancers and virtual machines defined. I do not want to explain Terraform in detail here. If you are interested in this I suggest you have a look on the excellent [terraform registry](https://registry.terraform.io/providers/hetznercloud/hcloud/latest/docs) documentation. It gives you a nice introduction for each resource. You do not have to edit one of these files. They are ready to go as they are. For provisioning the infrastructure we can do the following: ```bash $ export HCLOUD_TOKEN="<YOUR HCLOUD TOKEN>" $ terraform init $ terraform apply ``` `terraform apply` will ask you for a cluster name and will prompt you for confirmation later. After only a few seconds (wow), you should see a JSON configuration in green letters. This means everything has been successfuly and the infrastructure is starting right now. You might have noticed the `terraform.tfstate` file already. Do not lose it, it stores the status quo of your infrastructure configuration. Next we can create our first `kubeone.yaml` configuration file as input for KubeOne: ```yaml apiVersion: kubeone.io/v1beta1 kind: KubeOneCluster versions: kubernetes: '1.19.3' cloudProvider: hetzner: {} external: true ``` Pretty simple, isn't it? If this is done we save our json output into a json file via: `terraform output -json > output.json`. Now we get to our final line: `kubeone apply --manifest kubeone.yaml --tfjson output.json`. This line will apply the KubeOne configuration to our current Terraform configuration and install the cluster in our infrastructure. Your output should be similar to this one here: ```log INFO[22:38:58 CET] Determine hostname... INFO[22:38:59 CET] Determine operating system... INFO[22:39:00 CET] Running host probes... The following actions will be taken: Run with --verbose flag for more information. + initialize control plane node "avency-control-plane-1" (192.168.0.4) using 1.19.3 + join control plane node "avency-control-plane-2" (192.168.0.3) using 1.19.3 + join control plane node "avency-control-plane-3" (192.168.0.5) using 1.19.3 + ensure machinedeployment "avency-pool1" with 1 replica(s) exists Do you want to proceed (yes/no): yes INFO[22:43:14 CET] Determine hostname... INFO[22:43:14 CET] Determine operating system... INFO[22:43:14 CET] Installing prerequisites... INFO[22:43:14 CET] Creating environment file... node=116.203.150.238 os=ubuntu INFO[22:43:14 CET] Creating environment file... node=116.203.202.241 os=ubuntu INFO[22:43:14 CET] Creating environment file... node=116.203.225.170 os=ubuntu INFO[22:43:14 CET] Configuring proxy... node=116.203.202.241 os=ubuntu INFO[22:43:14 CET] Installing kubeadm... node=116.203.202.241 os=ubuntu INFO[22:43:14 CET] Configuring proxy... node=116.203.225.170 os=ubuntu INFO[22:43:14 CET] Installing kubeadm... node=116.203.225.170 os=ubuntu INFO[22:43:14 CET] Configuring proxy... node=116.203.150.238 os=ubuntu INFO[22:43:14 CET] Installing kubeadm... node=116.203.150.238 os=ubuntu .... INFO[22:49:54 CET] Installing machine-controller... INFO[22:49:57 CET] Installing machine-controller webhooks... INFO[22:49:58 CET] Waiting for machine-controller to come up... INFO[22:50:34 CET] Creating worker machines... ``` KubeOne could take a few minutes for setting everything up, but in the end you should be greeted with a `*-kubeconfig` file in the current directory. I suggest you setup a `configs` directory in `$HOME/.kube/configs`. This way you can store every Kubernetes config for multiple clusters in one directory. Additionally you should set this environment variable in your `zshrc` or `bashrc` configuration: `KUBECONFIG="$(find ~/.kube/configs/ -type f -exec printf '%s:' '{}' +)"`. It will load all Kubernetes configuration files and construct a path from them. Big thanks to my friend Morre for the tip. If you moved the config file to the right direction and restarted your shell you should be able to list all nodes: `kubectl get nodes`. The biggest advantage of KubeOne over the previous mentioned method is that you can easily scale your cluster up and down. This works, because KubeOne ships a `machine-controller` for deploying or deleting worker nodes. For scaling your cluster up and down just modify the `machinedeployment` resource in the `kube-system` namespace or use the `kubectl scale` command: `kubectl scale -n kube-system machinedeployment <machinedeployment-name> --replicas=5`. You are even able to scale your cluster to zero: `kubectl scale -n kube-system machinedeployment <machinedeployment-name> --replicas=0`. Take in mind that you need modify your `output.tf` or KubeOne configuration manifest if you scale up or down, otherwise you might end up deleting/adding resources you do not want. Apropos deleting, if you want to get rid of everything and this article sucks just do a `terraform destroy`. This should destroy all configured resources that got created via Terraform. Playing around with this for multiple hours cost me around 20 cent. I hope you do not forget to delete your resources after playing around. Luckily Hetzner is not that expensive and you should not wake up with a €2000 bill the next day (not looking at you Amazon AWS...). Next time we will dive into bootstrapping our first Kubernetes cluster without machine-controller and static worker nodes. ## Where to Learn More * <https://docs.kubermatic.com/kubeone/v1.0/> * <https://registry.terraform.io/providers/hetznercloud/hcloud/latest/docs> * <https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/> * <https://www.kubermatic.com/blog/kubeone-oidc-authentication-audit-logging/> * <https://www.kubermatic.com/resources/demo-deploy-and-manage-your-cluster-everywhere-with-kubeone/> --- ## How to Migrate 100 Clusters to Google Cloud Without Downtime - **URL:** https://www.kubermatic.com/resources/how-to-migrate-100-clusters-to-google-cloud-without-downtime/ - **Date:** 2024-03-22 - **Description:** Learn more about the differences between migrating one or one hundred clusters with productive workloads. # How to Migrate 100 Clusters from On-Prem to Google Cloud Without Downtime ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Watch the recording to see how an automated solution could look like in the future and what steps are missing Have you ever thought about migrating your Kubernetes clusters to Google Cloud to get your services closer to your customers? Yes? Us too! Join us on an interactive journey to discover the main challenges of live migration at scale of etcd’s, traffic routing and application workloads from your on-premise platform to GCP. The talk will discuss the current state of the technical concept, known problems and insides of the already proven migration steps for stateless workloads. **As part of the journey, we’ll see** - The differences between migrating one or one hundred clusters with productive workloads - What parts can be automated? - What steps may need to be manual? **Speakers: Tobias Schneck, Senior Software Engineer at Kubermatic & Manuel Stößel, Systems Architect at Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Exposing Apps With Services - **URL:** https://www.kubermatic.com/blog/exposing-apps-with-services/ - **Date:** 2026-05-07 - **Description:** Learn more about how to expose an application to the outside world via Kubernetes Services. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Seyi Ewegbemi In this guide, we will discuss how to expose an application to the outside world via Services. We will cover five different types of Services and their usage. Basic knowledge of [Pod](https://www.kubermatic.com/blog/introduction-to-pods/) and [Deployment](https://www.kubermatic.com/blog/introduction-to-kubernetes-replicasets/) is suggested to follow the hands-on practice on this part of the series. ## Services in Kubernetes A Kubernetes Service is a Kubernetes object which enables cross-communication between different components within and outside a Kubernetes cluster. It exposes Kubernetes applications to the outside world while simultaneously allowing network access to a set of Pods within and outside of a Kubernetes cluster. ### Creating a Service You can create a Service just like any of the Kubernetes objects we have made before, by creating a YAML manifest file, but with the kind value set to “Service.” ```yaml apiVersion: v1 kind: Service metadata: name: ## name of the Service spec: selector: app: ## Serves as a label which should be refrenced in a Pod / Deployment manifest file department: ##same as above ports: - protocol: ##The default is TCP port: ##Exposes the service within the cluster. Also, other Pods use this to access the Service targetPort: ##The service sends request while containers accept traffic on this port. ``` The above manifest represents a Service configuration template without specifying the Service type. **Question:** Why can’t I use the Pod’s external IP instead of a Service as mentioned in [part three](https://www.kubermatic.com/blog/introduction-to-pods/) of this series? ### Why Services and Not Pod IP? The Pod IP address is dynamic, which means it could change any moment. For example, when a Pod crashes or is deleted and another one comes up with the help of a [ReplicaSet](https://www.kubermatic.com/blog/introduction-to-replicasets-deployment/), the new Pod has a different IP address from the terminated one. This makes the Pod IP address unstable which can result in application errors. However, managing a connection to a Pod with a Service creates a stable IP address to reach the Pod at. ### Service Types There are five different types of Service: 1. ClusterIP (default) 2. Node Port 3. ExternalName 4. Headless 5. Load balancer #### ClusterIP This is the default Service type. It establishes a connection between different Services and applications using an internal cluster virtual IP. This type of Service is only reachable within the cluster. **Creating a Service with ClusterIP** To start these exercises, you need to have a running Kubernetes cluster. You can easily create a Kubernetes cluster on any environment with[ KubeOne](https://github.com/kubermatic/kubeone#getting-started). Check the [Getting Started](https://github.com/kubermatic/kubeone#getting-started) guide for instructions. Alternatively, you can simply use the [Kubernetes playground](https://labs.play-with-k8s.com/) for practising purposes. **Step 1:** First, create a Deployment and make sure that the **`spec.selector.matchLabels.app`** value in the Deployment manifest file matches the **`spec.template.metadata.labels.app`** value in the same Deployment manifest as well as the **`spec.selector.app`** value in the Service manifest file. The manifest file will look like this: ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: my-deployment spec: replicas: 2 strategy: type: Recreate selector: matchLabels: app: my-app template: metadata: labels: app: my-app env: prod spec: containers: - name: my-deployment-container image: nginx ``` Use `kubectl create` command to create the Deployment. This configuration will create a Deployment with two Pods that we will expose with a ClusterIP service. Once the Pods are running by checking it using `kubectl get pods` command, create a Service with the below configuration: **Step 2:** Create the Service Create a YAML file: ```bash $ vim clp_service.yaml ``` Copy and paste the below manifest file into your file, save, and exit: ```yaml apiVersion: v1 kind: Service metadata: name: example-prod spec: selector: app: my-app env: prod type: ClusterIP ports: - protocol: TCP port: 80 targetPort: 8080 ``` **Step 3:** Deploy your Service to the cluster. ```bash $ kubectl create -f clp_service.yaml service/example-prod created ``` **Step 4:** Make sure both your Pods and the Service are running by checking their statuses. Check the status of the service: ```bash $ kubectl get service example-prod ``` ```bash NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE example-prod ClusterIP 10.107.61.93 &lt;none> 80/TCP 13s ``` Check the status of the Pods to get their names: ```bash $ kubectl get pods ``` ```bash NAME READY STATUS RESTARTS AGE my-deployment-6b9b97d749-g5d2w 1/1 Running 0 10m my-deployment-6b9b97d749-w9tq5 1/1 Running 0 10m ``` **Step 5:** Determine the Service IP and Port.\ Exec into one of the containers: ```bash $ kubectl exec -it my-deployment-6b9b97d749-g5d2w -- bin/bash root@my-deployment-6b9b97d749-g5d2w: ``` Check the Service info in the Container: ```bash root@my-deployment-97cfc859f-q9dqh:/# printenv | grep SERVICE ``` ```bash KUBERNETES_SERVICE_HOST=10.96.0.1 KUBERNETES_SERVICE_PORT=443 KUBERNETES_SERVICE_PORT_HTTPS=443 ``` As can be seen above, the created Service was not part of the output. Why? This will be the case if you create the Deployment before the Service. You can simply correct it by deleting all the instances of the Pod so that they can be re-created when the Service is already running. ```bash $ kubectl delete pod my-deployment-6b9b97d749-g5d2w my-deployment-6b9b97d749-w9tq5 pod "my-deployment-6b9b97d749-g5d2w" deleted pod "my-deployment-6b9b97d749-w9tq5" deleted ``` Check the status of the Pods: ```bash $ kubectl get pods ``` ```bash NAME READY STATUS RESTARTS AGE my-deployment-6b9b97d749-48d27 1/1 Running 0 21s my-deployment-6b9b97d749-gsrwp 1/1 Running 0 21s ``` Exec into one of the Containers again: ```bash $ kubectl exec -it my-deployment-6b9b97d749-48d27 -- bin/bash root@my-deployment-6b9b97d749-48d27:/# ``` Check the Service info in the Container: ```bash root@my-deployment-6b9b97d749-48d27:/# printenv | grep SERVICE ``` ```bash KUBERNETES_SERVICE_PORT_HTTPS=443 ## Default Service name and Port on the Cluster KUBERNETES_SERVICE_PORT=443 EXAMPLE_PROD_SERVICE_HOST=10.107.61.93 ##Service IP as shown in the Service status KUBERNETES_SERVICE_HOST=10.96.0.1 ## Kubernetes IP already on the cluster EXAMPLE_PROD_SERVICE_PORT=80 ##Service name and Port specified in the Service YAML file. ``` As can be seen here, the Service name, Port, and host values are output in the container. This is possible because both the Service and the Pod are running on the same Cluster and the Service was created before the Pod/Deployment. ### Node Port This type of Service allows external accessibility to a Pod on a node. It receives an external request from clients or users and maps it into the Pod’s target-port and Service port. It also exposes an application externally with the help of a NodeIP and NodePort which exposes a port on every node. The NodePort range is 30000 – 32767; declaration outside this range is impossible. You can assign the NodePort manually in the manifest file or allow Kubernetes to assign it dynamically within the stipulated range. #### Creating a Service with NodePort **Step1:** Create a YAML file: ```bash $ vim NP_service.yaml ``` **Step2:** Copy and paste the below manifest into your YAML file, save, and exit: ```yaml apiVersion: v1 kind: Service metadata: name: example-prod spec: type: NodePort selector: app: my-app env: prod ports: - nodePort: 32410 protocol: TCP port: 80 targetPort: 80 ``` **Step 3:** Apply the manifest to the cluster. ```bash $kubectl create -f NP_service.yaml service/example-prod created ``` **Step 4:** Check the status of the Service with the `kubectl get service` command. **ExternalName** This Service type uses DNS in place of a selector and creates an internal **CNAME** DNS entry that aliases another. It has no port or proxying but only references the endpoints outside the cluster. ```yaml apiVersion: v1 kind: Service metadata: name: example-prod spec: type: ExternalName externalName: example.com ``` **Headless Service** This is a Service type where cluster IP is not allocated. No load balancing or proxying is done by this Service type, instead allows direct connection to a Pod. It also displays the list of the Pod IPs when a DNS query for headless Services is run.\ \ **Creating a Headless Service** You can create a Headless Service just like any other Services but the ClusterIP property value must be set to none in the YAML manifest file. The configuration data will look like this: ```yaml apiVersion: v1 kind: Service metadata: name: app spec: clusterIP: None selector: app: my-app env: prod ports: - protocol: TCP port: 80 targetPort: 80 ``` Use `kubectl create` command to create the Service and `kubectl get service` command to check the status of the Service. **LoadBalancer Service** This Service type shares the client’s requests across the servers continuously, efficiently, and evenly to protect against the excessive usage of server resources. The future addition or reduction of servers is made easier and more flexible with this Service type. It consists of both a ClusterIP address and NodePort and also works in conjunction with an external system to map a cluster external IP to the exposed Service. ![LoadBalancer Service Architecture](/static/exposing-apps-with-services_loadbalancer-service-architecture.png) #### Internal and External LoadBalancer Creating a load balancer Service can be done in two different ways, either internal or external.  ***The internal LoadBalancer***, which only has a private IP address on its node, is used to balance request traffic from clients within the same virtual network.  ***The external LoadBalancer***, on the other hand, has public IP addresses and it is used to balance external request traffic from clients outside the cluster.  **Getting Traffic into your Cluster** You can get traffic to your cluster using an external LoadBalancer together with a cloud provider that supports the external LoadBalancer. Below, we will walk you through the steps to create an external LoadBalancer as well as getting your public IP address for testing its functionality.  **Setting-up external LoadBalancers** Before we begin, make sure your Kubernetes cluster is running and kubectl command-line tool is configured to communicate with the cluster. If you do not have a running Kubernetes cluster, you can create one using [KubeOne](https://github.com/kubermatic/kubeone). **Step1:** Create a YAML file: ```bash $ vim LB_service.yaml ``` **Step2:** Copy and paste the below manifest into your YAML file, save, and exit: ```yaml apiVersion: v1 kind: Service metadata: name: example-prod spec: type: LoadBalancer selector: app: my-app env: prod ports: - protocol: TCP port: 80 targetPort: 80 ``` **Step 3:** ```bash $ kubectl create -f LB_service.yaml service/example-prod created ``` **Step 4:** Check the status of the Service: ```bash $ kubectl get service example-prod ``` ```bash NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE example-prod LoadBalancer 10.240.19.54 afe...61723.eu-central-1.elb.amazonaws.com 80:30592/TCP 15m ``` **Step 5:** Find the created Service’s IP address: ```bash $ kubectl describe service example-prod ``` ```bash Namespace: default Labels: &lt;none> Annotations: &lt;none> Selector: app=my-app,env=prod Type: LoadBalancer IP: 10.240.19.54 LoadBalancer Ingress: xxx.xxx.xxx Port: &lt;unset> 80/TCP TargetPort: 80/TCP NodePort: &lt;unset> 30592/TCP Endpoints: 172.25.0.11:80,172.25.0.12:80 Session Affinity: None External Traffic Policy: Cluster Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal EnsuringLoadBalancer 21m service-controller Ensuring load balancer Normal EnsuredLoadBalancer 20m service-controller Ensured load balancer ``` The IP address is listed in front of the LoadBalancer Ingress field marked with `xx.xxx.xxx`. **Service Types Architecture** The below image provides an overview of the Service types architecture. ![Service Types Architecture](/static/exposing-apps-with-services_service-types-architecture.png) Kubernetes Service is one of the essential objects in Kubernetes because of its important functionalities including communication and load balancing traffic across Pods for proper resource usage, providing a stable IP, and solving the problem of unstable Pod IP when a Pod dies or when a container in a Pod restarts.  The next parts in our series will deal with keeping application state. We will show you how to configure an application using files and environment variables, keeping your data secret (Kubernetes Secret), and how you can use a Configmap to store non-sensitive data among others. If you have any questions or comments about Service or other Kubernetes objects, feel free to get in touch with us [here.](mailto:marketing@kubermatic.com) ## Learn More * Visit the official [Kubernetes website](https://kubernetes.io/docs/concepts/services-networking/service/) for more resources on Kubernetes Service * Learn more about using a Service to expose your app [here ](https://kubernetes.io/docs/tutorials/kubernetes-basics/expose/expose-intro/) * Learn more about [external load-balancers here](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/) --- ## Joining Forces with Darumatic - **URL:** https://www.kubermatic.com/blog/joining-forces-with-darumatic-to-empower-devops-teams-across-clouds/ - **Date:** 2026-05-07 - **Description:** Learn how DevOps teams benefit from the strategic partnership by operating Kubernetes without vendor lock-in. - **Categories:** Company - **Tags:** Announcements - **Authors:** Kristin Wittig Today, we are  excited to announce a strategic partnership with Darumatic, the go to DevOps consultancy in Australia/Oceania. The partnership empowers DevOps teams to scale their organization across private and public clouds. By combining Darumatic’s strong footprint in Australia with our leading position in Europe, we are happy to further strengthen our international presence. ## What Benefits Will the Partnership Bring for Customers? Darumatic provides professional services to transform and optimize DevOps organizations. With Kubermatic Kubernetes Platform, DevOps teams benefit from an intuitive self-service platform to operate Kubernetes without vendor lock-in. Together, we deliver a comprehensive offering to build, scale and automate DevOps organizations across private and public clouds. Joining forces with Darumatic is an exciting and strategically important next step for us. We are currently furthering our international expansion and the partnership is clearly a meaningful milestone on that way. ## About Darumatic Darumatic DevOps Consulting provides professional services to transform and optimize DevOps organizations. Darumatic’s broad expertise covers all things cloud native, DevOps, Kubernetes and Software Development. The team consists of hands-on developers, architects, infrastructure engineers and automation engineers with a passion for agile and result-oriented work. ## Where to Learn More * [About Darumatic](https://darumatic.com/) * Joint Webinar With Darumatic: [Empower Your DevOps Organization With Kubernetes](https://www.youtube.com/watch?v=eGJfYpXa1wc&t=1901s) * [Find KKP on Github](https://github.com/kubermatic/kubermatic) * [How to Become a Partner at Kubermatic](https://www.kubermatic.com/partners/) --- ## How the Pandemic Makes You Emerge as a Digital Leader - **URL:** https://www.kubermatic.com/resources/why-the-pandemic-is-a-forcing-function-for-cloud-native/ - **Date:** 2023-08-28 - **Description:** Learn how digital leaders successfully master the transformation towards digital operations and digital growth in a changed world. # How the Pandemic Makes You Emerge as a Digital Leader ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Ebook ## Read the ebook to not sacrifice on innovation, agility and business success The global pandemic has brought on many challenges for people, organizations and countries. Leadership figures have faced the biggest test seen in recent years, which was met with the chance to future-proof their business. Given the sudden surge in demand for digital offerings, businesses need to have a long-term perspective on both digital operations and digital growth. From an IT perspective, this can only be successful if you: - Increase development speed and investment - Reduce operational cost and shift resources towards innovation - Leverage automation from development to operations If our form couldn't load correctly – This can have multiple reasons like ad blocker, not accepted cookies, JavaScript deactivated. However, you can still get in touch with us! Simply click on the button below, and you'll be able to submit the form and reach out to us for any inquiries or assistance you need. [Open form](https://share.hsforms.com/1mmOlZ5_LRdKv0iGaAfmY0g2piu8) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Quick and Easy Kubernetes Deployments With KubeOne - **URL:** https://www.kubermatic.com/blog/quick-and-easy-kubernetes-deployments-with-kubeone/ - **Date:** 2026-05-07 - **Description:** Learn more about how to use KKP to automate your Kubernetes operations at scale. - **Categories:** Products - **Tags:** KKP - **Authors:** Marko Mudrinić Following our first blog post of the [Getting Started with Kubermatic Kubernetes Platform](/blog/automated-multi-cluster-kubernetes-lifecycle-management/) webinar series, this second part continues on the path of showing you how to use KKP to automate your Kubernetes operations at scale. Specifically, we will show you how Kubermatic KubeOne fits into the KKP architecture. Kubermatic KubeOne is an open source, provider-neutral and feature-complete tool to deploy and manage the initial Kubernetes cluster needed to install KKP. It installs and provisions Kubernetes and upgrades, repairs and un-provisions the cluster.  We walk you through these steps in our **[webinar about deploying a Kubernetes cluster using KubeOne](https://www.youtube.com/watch?v=1D5Vd_z7wJY&t=108s).** ## Get to Know KubeOne Kubermatic Kubernetes Platform is an operator that needs to run on Kubernetes; KubeOne comes in to help manage clusters like Kubernetes help manage workloads.  KubeOne supports: * Various node OS’es  * All upstream-supported Kubernetes versions  * The full Kubernetes cluster lifecycle (provision, upgrade, repair, unprovision clusters) * Any provider and infrastructure - including on-prem and bare metal  * Integrating with Terraform * Accessing non-publicly exposed instead over bastion host/SSH jump host * Proxy environments KubeOne automates control plane and worker provisioning, is compatible with kubeadm by using it and its declarative cluster declaration brings reproducibility.  ### Creating Clusters on AWS **Step 1:** Create instance and infrastructure to be used by Kubernetes  * KubeOne comes with example Terraform scripts that can be used to get started  **Step 2:** Build KubeOne configuration manifest  * This defines:  * * Which Kubernetes version will be installed * What machines will be used * How the cluster will be provisioned * What features will be enabled * The easiest way to get a manifest is to use the kubeone config print command The KubeOne configuration manifest looks like: ```yaml apiVersion: kubeone.io/v1beta1 kind: KubeOneCluster versions: kubernetes: '1.18.6' cloudProvider: aws: {} ``` **Step 3:** Run `kubeone install` command ### Upgrading KubeOne Clusters  *Scope of the Upgrade Process* KubeOne takes care of: * Upgrading kubeadm and kubelet binaries * Running kubeadm upgrade on all control plane nodes * Upgrading components and addons deploy by KubeOne * Optionally upgrading all MachineDeployments objects to the desired Kubernetes version.  Upgrades are done in-place; KubeOne connects to nodes over SSH and runs commands needed to upgrade the node. Worker nodes managed by Kubermatic machine-controller are upgraded using the rolling-upgrade strategy, meaning the old nodes are replaced with the new ones. KubeOne Static Workers are upgraded in-place, similar to the control plane nodes. *Prerequisites* KubeOne does a set of ‘preflight checks’ to make sure the prerequisites are satisfied, including: * The cluster has been provisioned; Docker, Kubelet and Kubeadm are installed * Information about nodes from the Kubernetes API matches what we have in the KubeOne configuration (and Terraform state file) * All nodes are healthy * The [Kubernetes version skew policy](https://kubernetes.io/docs/setup/release/version-skew-policy/) is satisfied Once the upgrade process starts for a node, KubeOne applies the kubeone.io/upgrade-in-progress label on the Node object. The label is used as a lock mechanism, so if an upgrade fails or it’s already in progress, you can’t start it again. We recommend that you backup your cluster before running the upgrade process, which you can do using the [Backups Addons](https://docs.kubermatic.com/kubeone/v1.0/maintenance/backups-addon/). Before running an upgrade, always ensure that your KubeOne version supports upgrading to the desired Kubernetes version. You can find more information about supported Kubernetes versions in the [Compatibility document](https://docs.kubermatic.com/kubeone/v1.0/compatibility_info/). You can check what KubeOne version you’re running using the kubeone version command. *Upgrading the Cluster* You need to update the KubeOne configuration manifest to use the desired Kubernetes version by changing the versions.Kubernetes field. As per Kubernetes Skew Policy, it’s only possible to upgrade to the next minor release, or to any patch release as long as the minor version is the same or the next one. After modifying the configuration manifest, you can use the apply command to run an upgrade. The kubeone.yaml file is the configuration manifest and the tf.json file is the Terraform state file (which can be omitted if the Terraform Integration is not used). The --upgrade-machine-deployments flag ensures that worker nodes will be upgraded as well. ```bash kubeone apply --manifest kubeone.yaml -t tf.json --upgrade-machine-deployments ``` The apply command: * Analyzes the given instances * Verifies that there is Kubernetes running on those instances * Runs the preflight checks * Offers you the chance to upgrade the cluster if needed You’ll be asked to confirm your intention to upgrade the cluster by typing yes. ```bash INFO[13:59:27 CEST] Determine hostname… INFO[13:59:31 CEST] Determine operating system… INFO[13:59:32 CEST] Running host probes… INFO[13:59:33 CEST] Electing cluster leader… INFO[13:59:33 CEST] Elected leader "ip-172-31-220-51.eu-west-3.compute.internal"… INFO[13:59:36 CEST] Building Kubernetes clientset… INFO[13:59:36 CEST] Running cluster probes… The following actions will be taken: Run with --verbose flag for more information. ~ upgrade control plane node "ip-172-31-220-51.eu-west-3.compute.internal" (172.31.220.51): 1.18.5 -> 1.18.6 ~ upgrade control plane node "ip-172-31-221-177.eu-west-3.compute.internal" (172.31.221.177): 1.18.5 -> 1.18.6 ~ upgrade control plane node "ip-172-31-222-48.eu-west-3.compute.internal" (172.31.222.48): 1.18.5 -> 1.18.6 ~ ensure nodelocaldns ~ ensure CNI ~ ensure credential ~ ensure machine-controller ~ upgrade MachineDeployments ``` `Do you want to proceed (yes/no):` After confirming your intention to upgrade the cluster, the process will start. It usually takes 5-10 minutes for a cluster to be upgraded. At the end, you should see output such as the following one: ```bash INFO[13:59:55 CEST] Determine hostname… INFO[13:59:55 CEST] Determine operating system… INFO[13:59:55 CEST] Generating kubeadm config file… INFO[13:59:56 CEST] Uploading config files… node=172.31.222.48 INFO[13:59:56 CEST] Uploading config files… node=172.31.220.51 INFO[13:59:56 CEST] Uploading config files… node=172.31.221.177 INFO[13:59:57 CEST] Building Kubernetes clientset… INFO[13:59:58 CEST] Running preflight checks… INFO[13:59:58 CEST] Verifying that Docker, Kubelet and Kubeadm are installed… INFO[13:59:58 CEST] Verifying that nodes in the cluster match nodes defined in the manifest… INFO[13:59:58 CEST] Verifying that all nodes in the cluster are ready… INFO[13:59:58 CEST] Verifying that there is no upgrade in the progress… INFO[13:59:58 CEST] Verifying is it possible to upgrade to the desired version… INFO[13:59:58 CEST] Labeling leader control plane… node=172.31.220.51 INFO[13:59:58 CEST] Draining leader control plane… node=172.31.220.51 INFO[14:00:07 CEST] Upgrading kubeadm binary on the leader control plane… node=172.31.220.51 INFO[14:00:21 CEST] Running 'kubeadm upgrade' on leader control plane node… node=172.31.220.51 INFO[14:00:44 CEST] Upgrading kubernetes system binaries on the leader control plane… node=172.31.220.51 INFO[14:00:59 CEST] Uncordoning leader control plane… node=172.31.220.51 INFO[14:01:00 CEST] Waiting 30s to ensure all components are up… node=172.31.220.51 INFO[14:01:30 CEST] Unlabeling leader control plane… node=172.31.220.51 INFO[14:01:30 CEST] Labeling follower control plane… node=172.31.221.177 INFO[14:01:30 CEST] Draining follower control plane… node=172.31.221.177 INFO[14:01:30 CEST] Upgrading Kubernetes binaries on follower control plane… node=172.31.221.177 INFO[14:01:44 CEST] Running 'kubeadm upgrade' on the follower control plane node… node=172.31.221.177 INFO[14:01:55 CEST] Upgrading kubernetes system binaries on the follower control plane… node=172.31.221.177 INFO[14:02:14 CEST] Uncordoning follower control plane… node=172.31.221.177 INFO[14:02:14 CEST] Waiting 30s to ensure all components are up… node=172.31.221.177 INFO[14:02:44 CEST] Unlabeling follower control plane… node=172.31.221.177 INFO[14:02:44 CEST] Labeling follower control plane… node=172.31.222.48 INFO[14:02:44 CEST] Draining follower control plane… node=172.31.222.48 INFO[14:02:53 CEST] Upgrading Kubernetes binaries on follower control plane… node=172.31.222.48 INFO[14:03:10 CEST] Running 'kubeadm upgrade' on the follower control plane node… node=172.31.222.48 INFO[14:03:24 CEST] Upgrading kubernetes system binaries on the follower control plane… node=172.31.222.48 INFO[14:03:48 CEST] Uncordoning follower control plane… node=172.31.222.48 INFO[14:03:48 CEST] Waiting 30s to ensure all components are up… node=172.31.222.48 INFO[14:04:18 CEST] Unlabeling follower control plane… node=172.31.222.48 INFO[14:04:18 CEST] Downloading PKI… INFO[14:04:19 CEST] Downloading PKI files… node=172.31.220.51 INFO[14:04:20 CEST] Creating local backup… node=172.31.220.51 INFO[14:04:20 CEST] Ensure node local DNS cache… INFO[14:04:21 CEST] Activating additional features… INFO[14:04:22 CEST] Applying canal CNI plugin… INFO[14:04:34 CEST] Creating credentials secret… INFO[14:04:34 CEST] Installing machine-controller… INFO[14:04:37 CEST] Installing machine-controller webhooks… INFO[14:04:37 CEST] Waiting for machine-controller to come up… INFO[14:05:03 CEST] Upgrade MachineDeployments… ``` If the upgrade process fails, it’s recommended to continue manually and resolve errors. In that case, the kubeone.io/upgrade-in-progress label will prevent you from running KubeOne again, but you can remove it by using kubectl, such as: kubectl label node &lt;node-name> kubeone.io/upgrade-in-progress-. *Changing Cluster Properties Using KubeOne Upgrade* If you want to change some of the cluster properties (e.g. enable a new feature), you can use the upgrade command to reconcile the changes. Modify your manifest to include the desired changes, but don’t change the Kubernetes version (unless you want to upgrade the cluster), and then run the upgrade command with the --force flag: ```bash kubeone upgrade --manifest kubeone.yaml -t tf.json --force ``` Alternatively, the kubeone apply command can also be used: ```bash kubeone apply --manifest kubeone.yaml -t tf.json --force-upgrade ``` The --force flag instructs KubeOne to ignore the preflight errors, including the error saying that you’re trying to upgrade to the already running version. At the upgrade time, KubeOne ensures that the actual cluster configuration matches the expected configuration, and therefore the upgrade command can be used to modify cluster properties. ## Introduction to Machine-Controller and Cluster API ### Machine controller [Kubermatic machine-controller](https://github.com/kubermatic/machine-controller) is an open-source Cluster API implementation that takes care of: * Creating and managing instances for worker nodes * Joining worker nodes a cluster * Reconciling worker nodes and ensuring they are healthy Kubermatic machine-controller allows you to define all worker nodes as Kubernetes objects and, more precisely, as MachineDeployments. MachineDeployments work similar to core Deployments.  You provide the information needed to create instances, while machine-controller creates underlying MachineSet and Machine objects and, based on that, (cloud) provider instances. The (cloud) provider instances are then provisioned and joined to the cluster automatically by machine-controller. machine-controller watches all MachineDeployment, MachineSet, and Machine objects all the time. If any change happens, it ensures that the actual state matches the desired state. As all worker nodes are defined as Kubernetes objects, you can manage them using kubectl or by interacting with the Kubernetes API directly. This is a powerful mechanism because you can create new worker nodes, delete existing ones, or scale them up and down, using a single kubectl command. Kubermatic machine-controller works only with [natively-supported providers](https://docs.kubermatic.com/kubeone/v1.0/compatibility_info/). If your provider is natively-supported, we highly recommend using machine-controller. Otherwise, you can use KubeOne Static Workers. ### Cluster API Cluster API is a Kubernetes sub-project focused on providing declarative APIs and tooling to simplify provisioning, upgrading, and operating multiple Kubernetes clusters.  We use Cluster API for managing worker nodes, while control plane nodes are managed as described in the Cluster Provisioning and Management section. The Cluster API controller (e.g. Kubermatic machine-controller) is responsible for acting on Cluster API objects — Machines, MachineSets, and MachineDeployments. The controller takes care of reconciling the desired state and ensuring that the requested machines exist and are part of the cluster. You can learn more about the Cluster API by checking out the [Cluster API repository](https://github.com/kubernetes-sigs/cluster-api) and the [Cluster API documentation website](https://cluster-api.sigs.k8s.io/). ## Managing Worker Nodes KubeOne Static Workers are worker nodes provisioned by KubeOne using kubeadm. Similar to the control plane nodes, it’s expected that the user will create and maintain instances for static worker nodes. This is useful in cases where the infrastructure provider is not natively-supported. In this case, KubeOne will use the static worker nodes provided in the KubeOne Configuration Manifest. Static Workers Nodes are defined similarly to the control plane hosts, but they have their own API field called staticWorkers: ```bash # The list of nodes can be overwritten by providing Terraform output. # You are strongly encouraged to provide an odd number of nodes and # have at least three of them. # Remember to only specify your *master* nodes. controlPlane: hosts: - publicAddress: '1.2.3.4' privateAddress: '172.18.0.1' bastion: '4.3.2.1' bastionPort: 22 # can be left out if using the default (22) bastionUser: 'root' # can be left out if using the default ('root') sshPort: 22 # can be left out if using the default (22) sshUsername: ubuntu # You usually want to configure either a private key OR an # agent socket, but never both. The socket value can be # prefixed with "env:" to refer to an environment variable. sshPrivateKeyFile: '/home/me/.ssh/id_rsa' sshAgentSocket: 'env:SSH_AUTH_SOCK' # Taints is used to apply taints to the node. # If not provided defaults to TaintEffectNoSchedule, with key # node-role.kubernetes.io/master for control plane nodes. # Explicitly empty (i.e. taints: {}) means no taints will be applied. taints: - key: "node-role.kubernetes.io/master" effect: "NoSchedule" # A list of static workers, not managed by MachineController. # The list of nodes can be overwritten by providing Terraform output. staticWorkers: hosts: - publicAddress: '1.2.3.5' privateAddress: '172.18.0.2' bastion: '4.3.2.1' bastionPort: 22 # can be left out if using the default (22) bastionUser: 'root' # can be left out if using the default ('root') sshPort: 22 # can be left out if using the default (22) sshUsername: ubuntu # You usually want to configure either a private key OR an # agent socket, but never both. The socket value can be # prefixed with "env:" to refer to an environment variable. sshPrivateKeyFile: '/home/me/.ssh/id_rsa' sshAgentSocket: 'env:SSH_AUTH_SOCK' # Taints is used to apply taints to the node. # Explicitly empty (i.e. taints: {}) means no taints will be applied. # taints: # - key: "" # effect: "" ``` ## Next Up If you have any questions or comments, please [get in touch with our team](https://www.kubermatic.com/contact-us/).  Our next installment in this series will continue in guiding you through getting started with Kubermatic Kubernetes Platform. ## Where to Learn More * Visit our [product page](https://www.kubermatic.com/products/kubermatic-kubernetes-platform/) * Watch the demo: [Automate Your Clusters Across Multi-Cloud with KKP](https://www.kubermatic.com/resources/automate-your-clusters-across-multi-cloud-with-kkp/) * [Find KKP on Github](https://github.com/kubermatic/kubermatic) --- ## Rego in a Nutshell - **URL:** https://www.kubermatic.com/blog/opa-rego-in-a-nutshell/ - **Date:** 2026-05-07 - **Description:** An Introduction to the Rego language used in Open Policy Agent - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Irina Lindt [In earlier articles from this series](https://www.kubermatic.com/blog/using-open-policy-agent-with-kubermatic/), we have demonstrated how to use Open Policy Agent (OPA) with Kubermatic Kubernetes Platform. Open Policy Agent uses its own native language, Rego, to define queries. This tutorial presents an overview of the main features of Rego which will allow you to implement your own policy in detail. Rego is a declarative language, which means that you can state what your queries should return instead of describing how to do it. It is designed to work with the nested structure of JSON and YAML documents. In this tutorial, we will show you some examples from the documentation and explain which features of Rego have been used. The following code is from [the demo repository](https://github.com/open-policy-agent/gatekeeper/blob/master/demo/agilebank/templates/k8sallowedrepos_template.yaml) with examples of Open Policy Agent usage. It defines a policy that limits image repos for containers to a list of allowed repos and outputs a descriptive error message in case of a violation. ```yaml apiVersion: templates.gatekeeper.sh/v1beta1 kind: ConstraintTemplate metadata: name: k8sallowedrepos spec: crd: spec: names: kind: K8sAllowedRepos validation: # Schema for the `parameters` field openAPIV3Schema: properties: repos: type: array items: type: string targets: - target: admission.k8s.gatekeeper.sh rego: | package k8sallowedrepos violation[{"msg": msg}] { container := input.review.object.spec.containers[_] satisfied := [good | repo = input.parameters.repos[_] ; good = startswith(container.image, repo)] not any(satisfied) msg := sprintf("container <%v> has an invalid image repo <%v>, allowed repos are %v", [container.name, container.image, input.parameters.repos]) } violation[{"msg": msg}] { container := input.review.object.spec.initContainers[_] satisfied := [good | repo = input.parameters.repos[_] ; good = startswith(container.image, repo)] not any(satisfied) msg := sprintf("container <%v> has an invalid image repo <%v>, allowed repos are %v", [container.name, container.image, input.parameters.repos]) } ``` The Rego part is separated by `rego: |`. The line `violation[{"msg": msg}]` specifies that in case of a violation, an error message will be stored in the variable `msg`. How exactly that error message should look is defined a few lines down, when the `msg` variable gets assigned. Now, look at the line `container := input.review.object.spec.containers[_]` which introduces several important concepts. * `Input` is a reserved global variable that contains the object that is handed to OPA for policy review. * Scalar values are created as `valuename :- value`. Here you create a scalar value named `container`. * The dot operator `.` lets you walk through the nested hierarchy of a YAML file. You can select for parameters as deeply nested as you want. * The underscore operator `_` stands for a variable which is not used outside of this query. Rego instantiates it at runtime with a unique variable. You can use the placeholder `_` several times in a query; they will get instantiated with different variables. The following example is a policy which states that a resource must provide all labels that it has keys for and they have to match the regular expression provided in `allowedRegex`. ```yaml apiVersion: templates.gatekeeper.sh/v1beta1 kind: ConstraintTemplate metadata: name: k8srequiredlabels spec: crd: spec: names: kind: K8sRequiredLabels validation: # Schema for the `parameters` field openAPIV3Schema: properties: message: type: string labels: type: array items: type: object properties: key: type: string allowedRegex: type: string targets: - target: admission.k8s.gatekeeper.sh rego: | package k8srequiredlabels get_message(parameters, _default) = msg { not parameters.message msg := _default } get_message(parameters, _default) = msg { msg := parameters.message } violation[{"msg": msg, "details": {"missing_labels": missing}}] { provided := {label | input.review.object.metadata.labels[label]} required := {label | label := input.parameters.labels[_].key} missing := required - provided count(missing) > 0 def_msg := sprintf("you must provide labels: %v", [missing]) msg := get_message(input.parameters, def_msg) } violation[{"msg": msg}] { value := input.review.object.metadata.labels[key] expected := input.parameters.labels[_] expected.key == key # do not match if allowedRegex is not defined, or is an empty string expected.allowedRegex != `` not re_match(expected.allowedRegex, value) def_msg := sprintf("Label <%v: %v> does not satisfy allowed regex: %v", [key, value, expected.allowedRegex]) msg := get_message(input.parameters, def_msg) } ``` In this example you can see how to create functions within Rego. The function `get_message` is created twice with the same parameters, because it looks whether the field `parameters.message` is specified. If this is not the case, the first definition of the function is executed and it returns the default message. If a message is provided, the function returns the message. The first violation field in this example returns an additional parameter `details`. You can use that parameter to return the result of variables in your code which provide additional insight in the violation. In this example, it returns the variable in which the missing labels are stored. This example also displays all three forms of equality operators in Rego. The operator `x := 0` declares a local variable `x` and assigns it the value 0. The operator `x == 0` checks whether the value of `x` is 0. These two operators can only be used within rules. The operator `x = 0` can be used outside of rules. It functions both as a boolean and an assignment operator. In case the variable `x` has a value, it compares that value to 0. Otherwise it assigns the value 0 to `x`. This example also shows the two kinds of strings that can be used within Rego. You use the backticks for a raw string, and the quotes "" for an interpolated string in which you can print the value of variables. You can also use regular expressions in Rego strings. This example checks if the policy defines a suitable regular expression. The following example defines a policy that checks whether the container object specifies the required probes. ```yaml apiVersion: templates.gatekeeper.sh/v1beta1 kind: ConstraintTemplate metadata: name: k8srequiredprobes spec: crd: spec: names: kind: K8sRequiredProbes validation: openAPIV3Schema: properties: probes: type: array items: type: string probeTypes: type: array items: type: string targets: - target: admission.k8s.gatekeeper.sh rego: | package k8srequiredprobes probe_type_set = probe_types { probe_types := {type | type := input.parameters.probeTypes[_]} } violation[{"msg": msg}] { container := input.review.object.spec.containers[_] probe := input.parameters.probes[_] probe_is_missing(container, probe) msg := get_violation_message(container, input.review, probe) } probe_is_missing(ctr, probe) = true { not ctr[probe] } probe_is_missing(ctr, probe) = true { probe_field_empty(ctr, probe) } probe_field_empty(ctr, probe) = true { probe_fields := {field | ctr[probe][field]} diff_fields := probe_type_set - probe_fields count(diff_fields) == count(probe_type_set) } get_violation_message(container, review, probe) = msg { msg := sprintf("Container <%v> in your <%v> <%v> has no <%v>", [container.name, review.kind.kind, review.object.metadata.name, probe]) } ``` This example shows how the same violation can be true for different scenarios. In this case, the function probe_is_missing is defined for both the cases where the field probe is not defined and where it is empty. Both of these cases return true, meaning they violate the policy. ## Testing Rego provides a testing framework which you can use to test your policies before you execute them in production. It lets you define an example object and specify how OPA is expected to react to it. As an example, this is a simple policy and a test for it: Policy: ```yaml package kubernetes.admission deny[msg] { input.request.kind.kind == "Pod" image := input.request.object.spec.containers[_].image not startswith(image, "hooli.com") msg := sprintf("image fails to come from trusted registry: %v", [image]) } ``` Here is a Unit Test that checks that the policy violation was detected as expected: ```yaml package kubernetes.test_admission import data.kubernetes.admission test_image_safety { unsafe_image := { "request": { "kind": {"kind": "Pod"}, "object": { "spec": { "containers": [ {"image": "hooli.com/nginx"}, {"image": "busybox"} ] } } } } expected := "image 'busybox' comes from untrusted registry" admission.deny[expected] with input as unsafe_image } ``` ## Editor Plugins If you have a favorite IDE or editor, [check this list](https://www.openpolicyagent.org/docs/latest/editor-and-ide-support/) to see if there is a Rego plugin for it already. At the moment of the article, there are integration plugins for syntax highlighting and linting for Atom, Emacs, IntelliJ IDEA, Sublime Text, TextMate, Vim and VS Code. ## Rego Playground You can use the [Rego Playground](https://play.openpolicyagent.org/) to test your policies. It provides helpful examples and shows you the input, data and output of your Rego code in helpful panels. ## Conclusion Using this guide, you can understand the basics of the Rego language and review examples of how to create a policy. Additionally, we showed you how to test a policy before it is put in production. If you have any questions or want to get in touch with our team, [contact us here](https://www.kubermatic.com/contact-us/). --- ## When and Why Build Operators - **URL:** https://www.kubermatic.com/resources/when-and-why-build-operators/ - **Date:** 2022-12-01 - **Description:** Learn more about when it makes sense to create Operators. # When and Why Build Operators ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Create the Cloud Native Future Together With Kubernetes Operators In order to meet the increasing requirements of running more analytical jobs, it is crucial to get more insights into an organisations’ data and reap the benefits from it. To achieve this it is necessary to move the Big Data pipeline to the cloud. Doing so, this will meet the requirements of building and deploying analytical jobs within seconds with simplified user experience, scalability, and reliability. Fulfilling all expectations such as meeting standards of 99.999 availability, reduced operations, etc. is a massive challenge for cloud providers.  In order to master these challenges and to bring down operations and failure rates, Kubernetes and related technologies have been extremely helpful. But adopting Kubernetes is not the only Mantra which helps you achieve your goals: How to design your components on top of it also matters a lot. One of these useful components are Kubernetes Operators. The purpose of this talk is to discuss scenarios in which it makes sense to create such an Operator. **Rachit Arora, Senior Architect @ IBM** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Rapid Time-to-Market and Flexible Customer Service - **URL:** https://www.kubermatic.com/customers/fhe3/ - **Date:** 2026-06-23 - **Description:** How FHE3 leveraged Kubermatic KubeOne to deploy and operate the setup requested by their client # FHE3 Achieves Rapid Time-to-Market and Flexible Customer Service ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ![Montains](/static/mountains_hu_f58bb74088a3a86c.jpg) ![FH3 logo](/static/fhe3-logo.svg) ## The Challenge ### Meeting Customer Expectations for Cluster Management As an IT service provider, an FHE3 customer approached their team with the requirement to deploy and operate multiple Kubernetes clusters on an OpenStack environment in their data center. However, FHE3’s toolset and the customer’s environment did not work together. FHE3 needed to find a way to deliver the project according to the client’s needs despite the incompatible stack. ## The Solution ### Powerful Tools for Lifecycle Management Overcoming delays with the project and a shortage of manpower, FHE3 decided to use Kubermatic’s KubeOne cluster lifecycle management tool which fits any infrastructure. With a short time-to-market, FHE3 was able to leverage Kubermatic KubeOne to deploy and operate the setup requested by their client. ## The Impact ### Rapid Time-to-Market Without Kubermatic KubeOne, FHE3 would have had to duplicate their complete toolset on the customer’s data center in their environment. The speed of delivery was less than a quarter of the alternative approach thanks to the advantages of Kubermatic KubeOne. ## About FHE3 FHE3 is specialized in operating high availability systems and is dedicated to remaining very flexible to fulfill customer needs. The team looks after more than 500 physical servers and has over 2,500 virtual servers in use. 25,000 services are actively monitored in their own data center in Frankfurt (Main) and other locations worldwide. ![](/images/icons/servers.svg) ### 500 physical servers ![](/images/icons/cloud.svg) ### 2,500 virtual servers ![](/images/icons/globe.svg) ### 25,000 servers worldwide ![Double quotes image](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==) Kubermatic KubeOne's biggest strength is that it works out-of-the-box on a lot of cloud providers, as well as in on-premise and bare-metal environments. Having just one tool for all situations is a great thing. Kai Focke, Head of Projects & Operations EMEA at FHE3 [Read the Full Story](/static/Customer-Success-Story_FHE3.pdf) --- ## Rapid Progress on Cloud Native Transformation - **URL:** https://www.kubermatic.com/customers/dialog-data/ - **Date:** 2026-06-23 - **Description:** DialogData # Rapid Cloud Native Transformation by Building In-house Expertise ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ![Darts](/static/darts_hu_1412b90c5ad39c3.jpg) ![DialogData logo](/static/dialogdata-logo.svg) ## The Challenge ### Accelerate the Cloud Native Learning Curve DialogData, a software company focused on the e-commerce field, wanted to get ahead of their customers’ needs in their journey towards cloud native technologies. Additionally, they had built a complex internal system to manage their resources and projects. In order to reduce complexity and manual intervention, they decided to move their internal landscape to microservices on a cloud native system. ## The Solution ### Get in Cloud Native Expertise The DialogData team knew that they would have challenges and opportunities with integrating cloud native principles, architecture and tooling, and enlisted the help of Kubermatic to train their team. By training with cloud native experts, they sped up the learning curve and built the necessary in-house expertise to start transforming their internal landscape. ## The Impact ### Rapid Progress on Cloud Native Transformation The training has helped DialogData avoid many pitfalls and make good progress on their transformation process. Within a short time, they had their first services up and running and made it through a lot of larger updates in their support stack. With the new in-house knowledge acquired, DialogData can now put out new functionality faster. ## About DialogData DialogData has been enabling customers for digital success with outstanding expertise, commitment and tailored consultancy since 1992. As a certified SAP Commerce Cloud (formerly Hybris Commerce) partner, DialogData has successfully completed over 40 e-commerce projects with a team of over 20 SAP certified developers and trainers. DialogData has more than 90 employees and is headquartered in Munich with an additional presence in Berlin and Romania. ![](/images/icons/graph-chart.svg) ### 40+ e-commerce customers ![](/images/icons/people.svg) ### 90 employees wordwide ![](/images/icons/point-label.svg) ### Munich headquartered ![Double quotes image](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==) If you learn from an expert, you'll learn faster. It's more pleasant, more professional, and even less budget-intensive. Klaus Baumgartner, Project Leader at DialogData ![Klaus Baumgartner](/static/Klaus-Baumgartner.png) [Read the Full Story](/static/Customer-Success-Story_DialogData.pdf) --- ## Kubernetes 101 Part 6.3: Keeping the State of Apps - **URL:** https://www.kubermatic.com/resources/kubernetes-101-part-6-3-keeping-the-state-of-apps/ - **Date:** 2022-12-01 - **Description:** Learn how to deploy a number of equally specified Pods but in a defined order with fixed names and volume assignments. # Keeping the State of Apps Part 3 ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Watch this Epsiode of Our Webinar Series and Get Started With Keeping the State of Apps. In this episode, you will learn how to deploy a number of equally specified Pods but in a defined order with fixed names and volume assignments. These will be kept during scalings or rescheduling. Topics of this session: - How do StatefulSets differ from Deployments? - How to simply specify Pods inside of StatefulSets? - How to care for Volumes for the Pods? - Which role has a Service for StatefulSets? Speaker: Frank Müller, Solution Engineer & Team Lead PS @ Kubermatic ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Automated Multi-Cluster Kubernetes Lifecycle Management - **URL:** https://www.kubermatic.com/blog/automated-multi-cluster-kubernetes-lifecycle-management/ - **Date:** 2026-05-07 - **Description:** Learn how to automate multi cluster Kubernetes deployment and life cycle management with KKP. - **Categories:** Products - **Tags:** KKP - **Authors:** Sascha Haase The “old world” of IT operations used to entail high maintenace effort, costly downtimes, vendor lock-in, and developers waiting for their tickets to be processed. Enter: Kubermatic Kubernetes Platform. We saw the need for IT operations to be automated and infrastructure to be more scalable and flexible.  The speed at which enterprises need to digitize and scale cannot be done manually anymore. The “new world” of IT operations brought on by Kubernetes and cloud native technologies enables companies to have an automated, self-service platform that allows continuous freedom of choice and self-healing infrastructure. The platform can reconcile on its own without the need for manual intervention allowing IT operations to scale through software rather than people. ## How Does Kubermatic Kubernetes Platform Work?  Kubermatic Kubernetes Platform is a unified solution for automated cloud native operations creating an enterprise-grade self-service platform. It enables organizations to automate Kubernetes multi cluster lifecycle management with built in security and governance.  The key to this automation is our “Kubernetes in Kubernetes” architecture. The core of Kubernetes is just a reconciliation loop that allows users to specify the state of the world they require. The system will check if there is a difference between the declared and actual state and if there is, it will automatically make the changes to bring them in alignment. Kubermatic Kubernetes Platform extends this paradigm beyond just pods to also automate the Kubernetes cluster lifecycle itself. This allows the whole stack to run on Kubernetes. As an operator, there are three main benefits:  * The management footprint and cost are shrunk 5x - containerizing the control plane provides the density required to run at scale * Resiliency - a self-healing infrastructure reduces the meantime to recovery when things go wrong * Automation of operations allows scaling through software rather than people  Overall, Kubermatic Kubernetes Platform provides a single pane of glass to manage your complete Kubernetes infrastructure including hybrid, multi-cloud, and edge deployments. ## What Does It Take to Get Started with Kubermatic Kubernetes Platform?   Kubermatic Kubernetes Platform features streamlined tools to manage teams and projects, create clusters, and manage clusters. The steps below will demonstrate how to set up these functions for any new user.  ### Manage a Project and Users **Step 1:** To start the process, after you log in to Kubermatic, you will be greeted with the list of all projects you created or have been given access to. When first using Kubermatic, the list will be empty and you will need to create your first project. Click on the button in the top right to create your first project. Give it a descriptive name and click “Save”. After a short moment, your project will be ready. ![Kubermatic Kubernetes Platform Projects](/static/getting-started-with-kubermatic-kubernetes-platform_step1_creating-project.jpg) **Step 2:** To manage clusters, you need to select which project you would like to work in by either clicking the project in the project list or by using the dropdown in the top-left corner. ![Kubermatic Kubernetes Platform_Choosing Project](/static/getting-started-with-kubermatic-kubernetes-platform_step2_choosing-project.jpg) After selecting the current project, the menu items for managing clusters, members, and service accounts become active. ![Kubermatic Kubernetes Platform_Activating Menu Items for Managing Clusters](/static/getting-started-with-kubermatic-kubernetes-platform_step3_activating-menu-items-for-managing-clusters.jpg) **Step 3:** After selecting a project, click on “Members” in the menu to see the list of active members. If you are the owner, you can add and remove members of your project. To add a member, just like adding a project or a cluster, use the button above the member list. Add the email address of an existing user and define their role in the project. ![Kubermatic Kubernetes Platform_Adding New Members](/static/getting-started-with-kubermatic-kubernetes-platform_step4_adding-members.jpg) Owners have complete control over the project and can manage permissions. Editors have write access to your project and can manage clusters, nodes, and SSH keys. Viewers have read-only access and can only view the existing resources. You can change the role of a user or remove them altogether at any time. After adding a user to a project, the project will immediately show up in the user’s project list. **Step 4:** After selecting a project, click on “Service Accounts” in the menu to see the list of active service accounts. Similar to adding members, owners can add and remove service accounts and manage tokens that belong to them as well. To add a service account, use the button above the service account list to add the name and assign a group. ![Kubermatic Kubernetes Platform_Adding Service Accounts](/static/getting-started-with-kubermatic-kubernetes-platform_step5_adding-service-accounts.jpg) Editors and viewers have the same capabilities as members outlined in Step 3. You can change the role for a service account or remove them altogether at any time. ### Create a Cluster **Step 1:** Before you can manage clusters or SSH keys, select your current project. After choosing the project, the relevant menu items will become active. You can go to the clusters view by clicking on “Clusters” and then on the “Add Cluster” button in the top right corner to access the cluster wizard. **Step 2:** Choose a cloud provider and datacenter for your Kubernetes nodes to be deployed by Kubermatic Kubernetes Platform. Your nodes can be placed in any cloud allowed by your operations team. ![Kubermatic Kubernetes Platform_Selecting Cloud Provider](/static/getting-started-with-kubermatic-kubernetes-platform_step6_selecting-cloud-provider.jpg) **Step 3:** Next, you specify the cluster name which is how you will identify your Kubernetes cluster instance. Choose a name that is easy for you to remember and select your desired Kubernetes version. ![Kubermatic Kubernetes Platform_Specifying Cluster Name](/static/getting-started-with-kubermatic-kubernetes-platform_step7_specifying-cluster-name.jpg) **Step 4:**  Enter your provider-specific credentials so that Kubermatic Kubernetes Platform can configure your worker machines and integrate them into your cluster. This step varies depending on the selected provider; you will be asked for different provider credentials when choosing AWS or Google, for example. ![Kubermatic Kubernetes Platform_Entering Provider Specific Credentials](/static/getting-started-with-kubermatic-kubernetes-platform_step8_entering-provider-specific-credentials.jpg) **Step 5:** Finally, choose the number of nodes, operating system, and type of instances you will have for worker nodes. ![Kubermatic Kubernetes Platform_Choosing Number of Nodes, Operation System and Type of Instances](/static/getting-started-with-kubermatic-kubernetes-platform_step9_choosing-number-of-nodes.jpg) **Step 6:** Check whether all your configuration settings are correct and create your cluster! ![Kubermatic Kubernetes Platform_Checking Configuration Settings](/static/getting-started-with-kubermatic-kubernetes-platform_step10_checking-configuration-settings.jpg) ### Manage a Cluster **Cluster overview:** Using the navigation “Manage Cluster,” you can display your active clusters. ![Kubermatic Kubernetes Platform_Managing Clusters](/static/getting-started-with-kubermatic-kubernetes-platform_step11_managing-clusters.jpg) **Basic cluster information:** The dashboard provides you with all important cluster information. You can check the status of your master components and worker nodes. ![Kubermatic Kubernetes Platform_Basic Cluster Information in the Dashboard](/static/getting-started-with-kubermatic-kubernetes-platform_step12_dashboard.jpg) **Adding new nodes to your cluster:** You can easily extend your cluster with new worker nodes. Kubermatic Kubernetes Platform will automatically configure them and integrate them into your cluster. ![Kubermatic Kubernetes Platform_Adding New Nodes](/static/getting-started-with-kubermatic-kubernetes-platform_step13_adding-nodes.jpg) **Connect to the cluster:**  Kubermatic Kubernetes Platform automatically creates your cluster’s kubeconfig file. It can be downloaded using the icon button on the left of the “Add Node Deployment” button. ![Kubermatic Kubernetes Platform_Connecting to Your Cluster](/static/getting-started-with-kubermatic-kubernetes-platform_step14_creating-cluster-s-kubeconfig-file.jpg) To connect to your cluster, configure the kubectl command line tool to use your kubeconfig file. You are now able to proxy into your cluster and run your favorite kubectl commands! You can also use the “Open Dashboard” button to access the Kubernetes Dashboard. ![Kubermatic Kubernetes Platform_Kubernetes Dashboard](/static/getting-started-with-kubermatic-kubernetes-platform_step15_kubernetes-dashboard.jpg) ## Give It a Try These guidelines outline how to get started with Kubermatic Kubernetes Platform to increase your Kubernetes operations automation and scale efficiently. To try it out yourself, please [contact us](https://www.kubermatic.com/contact-us/) to request your personal demo. ## Where to learn more: * Visit our [product page](https://www.kubermatic.com/products/kubermatic-kubernetes-platform/) * [](https://www.kubermatic.com/resources/automate-your-clusters-across-multi-cloud-with-kkp/)Watch the demo: [Automate Your Clusters Across Multi-Cloud with KKP](https://www.kubermatic.com/resources/automate-your-clusters-across-multi-cloud-with-kkp/) * [Find KKP on Github](https://github.com/kubermatic/kubermatic) --- ## OIDC Authentification & Audit Logging With KubeOne - **URL:** https://www.kubermatic.com/blog/kubeone-oidc-authentication-audit-logging/ - **Date:** 2026-05-07 - **Description:** Learn more about Kubermatic Kubernetes Platform Container Engine, one of the first certified Kubernetes distributions worldwide. - **Categories:** Best Practices - **Tags:** KubeOne, Kubernetes - **Authors:** Christoph Mewes In this article we're going to set up a Kubernetes cluster with OIDC authentication and audit logging enabled. We prefer to manage our team associations via GitHub Teams and we want to grant permissions inside the cluster based on these teams, so we will use [Dex](https://dexidp.io/) as a bridge between Kubernetes and GitHub. Dex also allows us to integrate with other providers like Google or Azure to give non-developers access to the same cluster. ## Our Toolchain * [Terraform](https://www.terraform.io/) will provision three controlplane (master) nodes at Hetzner (but you can choose any provider supported by Kubermatic KubeOne (KK1)). * [Kubermatic KubeOne](https://github.com/kubermatic/kubeone) will then install Kubernetes. The controlplane will be available at `controlplane.example.com`. * [nginx-ingress](https://kubernetes.github.io/ingress-nginx/) and [cert-manager](https://cert-manager.io/) ensure that Dex can run securely inside the cluster. * [Dex](https://dexidp.io/) runs inside the cluster and will be available on `dex.controlplane.example.com`. It also takes care of connecting to various providers; in our case, that's GitHub. * The kubectl plugin [kubelogin](https://github.com/int128/kubelogin) is the final piece and will ensure that kubectl can obtain OIDC tokens automatically. ## Installation So, without further ado, let's get started. ### Terraform To begin with, we will use Terraform code to provision machines at Hetzner. Check out the [example repository](https://github.com/kubermatic-labs/kubeone-oidc-auditlog-example) for the full configuration. We can then apply it: ```bash $ git clone https://github.com/kubermatic-labs/kubeone-oidc-auditlog-example $ cd kubeone-oidc-auditlog-example $ export HCLOUD_TOKEN="your Hetzner Cloud token" $ cd terraform/ $ terraform init $ terraform apply $ cd .. ``` Once Terraform has finished, we are left with a number of VMs and a LoadBalancer in front of them. This LoadBalancer now needs a DNS record pointing to it. Our example cluster will use `controlplane.example.com`. Our development DNS is hosted at AWS, so in this case that means setting up an A record using Route53 that points to the LoadBalancer's IP. **Note:** Having DNS set up is critical for the Kubernetes installation to succeed. If the record is missing, kubeadm will get stuck trying to set up the nodes. ### Kubermatic KubeOne Kubermatic KubeOne will now take the output from Terraform and provision a Kubernetes cluster on it. Our KK1 configuration is rather simple at this stage, just as we like it: ```yaml apiVersion: kubeone.io/v1beta1 kind: KubeOneCluster versions: kubernetes: '1.19.3' cloudProvider: hetzner: {} external: true ``` We now need to generate the Terraform output and run KK1: ```bash $ terraform output -json terraform/ > output.json $ kubeone apply --manifest kubeone.yaml --tfjson output.json ``` After a few minutes, the cluster will be up and running and KK1 will have produced a kubeconfig file in the current working directory, named after the cluster (so in our example, `example-kubeconfig`). ```bash $ head example-kubeconfig apiVersion: v1 clusters: - cluster: certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0t.... server: https://controlplane.example.com:6443 name: example contexts: ``` ### nginx & cert-manager Next, we need to set up proper connectivity to the cluster. Dex requires HTTPS, so we need TLS certificates and this means we need cert-manager. For the ingress you can choose the ingress-controller of your choice; in this example, we're using the nginx-ingress-controller. We will be using [Helm 3](https://helm.sh/) to install all software, mostly because it's convenient and the Kubermatic Kubernetes Platform (KKP) already has neat charts ready for everything we need. Let's download the latest KKP release and use the bundled Helm charts: ```bash $ wget https://github.com/kubermatic/kubermatic/releases/download/v2.15.5/kubermatic-ce-v2.15.5-linux-amd64.tar.gz $ tar xzf kubermatic-ce-v2.15.5-linux-amd64.tar.gz charts ``` Install nginx first: ```bash $ helm \ --namespace nginx-ingress-controller \ upgrade \ --create-namespace \ --install \ nginx-ingress-controller \ ./charts/nginx-ingress-controller ``` This will create a new LoadBalancer service inside the `ingress-nginx` namespace and this LoadBalancer will handle all traffic for our example. ```bash $ kubectl -n ingress-nginx get svc nginx-ingress-controller NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx-ingress-controller LoadBalancer 10.107.95.30 1.2.3.4,192.168.0.9 80:31165/TCP,443:32548/TCP 2d3h ``` **Important:** On Hetzner, LoadBalancer Services need to be annotated with the desired location for the LoadBalancer. Add the annotation after installing nginx like so: ```bash $ kubectl \ --namespace nginx-ingress-controller \ annotate \ --overwrite \ service nginx-ingress-controller \ "load-balancer.hetzner.cloud/location=nbg1" ``` Once the annotation is setup, the `EXTERNAL-IP` column should switch from `<Pending>` to the actual IP. As we did for the controlplane, we now have to setup a DNS record for this LoadBalancer. Once again, this means Route53 in our case, pointing `dex.controlplane.example.com` to the LoadBalancer (`1.2.3.4` in the example above). Now, we can setup cert-manager. Install the CRDs first, then the Helm chart: ```bash $ kubectl apply -filename ./charts/cert-manager/crd/ $ helm \ --namespace cert-manager \ upgrade \ --create-namespace \ --install \ cert-manager \ ./charts/cert-manager ``` By default, the Helm chart will setup two ClusterIssuers: `letsencrypt-prod` and `letsencrypt-staging`. We will be using the `prod` variant for this example. Our cluster is now ready to receive traffic and can provide certificates for these apps that need them. We can continue with the next step: ### Dex Before we can install Dex, we need to create an OAuth application at GitHub. GitHub describes the process of [setting up an app](https://developer.github.com/apps/building-oauth-apps/creating-an-oauth-app/) in detail, so check out their documentation. Make sure to configure `https://dex.controlplane.example.com/dex/calback` as the callback URL for the app and when that's done, note down the client ID and client secret. To configure the Helm chart for Dex, create a `values.yaml` like so: ```yaml dex: ingress: host: dex.controlplane.example.com # This lists all the various login methods that should be available to # users. In our example this is only GitHub, but it can be extended to # include Google, Azure, static credentials, ... connectors: - type: github id: github name: GitHub config: clientID: <your app's client ID here> clientSecret: <your app's client secret here> redirectURI: https://dex.controlplane.example.com/dex/callback # you can configure the connector further, for example by # restricting it to only a certain org or team. These restrictions # depend on the provider; check the Dex documentation for more info. #orgs: #- name: exampleorg # This Dex installation will only have 1 client (consumer), the Kubernetes # cluster itself. clients: - # The ID is important and needs to match what we will later configure # for the kube-apiserver. Remember that we called it "kubernetes". id: kubernetes name: Kubernetes Cluster Authentication # generate a random secret here; note that this will be put into the # final kubeconfig, so it's not really that secret # `cat /dev/urandom | tr -dc A-Za-z0-9 | head -c32` secret: "...." RedirectURIs: # for authentication from kubectl oidc-login plugin - http://localhost:8000 ``` Time to install Dex! As this Dex is most certainly a cluster service, we install it into `kube-system`. Note that for historical reasons, the chart is called `oauth` in the KKP distribution. ```bash $ helm \ --namespace kube-system \ upgrade \ --create-namespace \ --install \ dex \ ./charts/oauth ``` If everything worked out, you should be able to see the Certificate for Dex turning from READY=False to True: ```bash $ kubectl -n kube-system get certificates NAME READY SECRET AGE dex True dex-tls 3m ``` Great success! ### kubelogin So, let's summarize where we are: The cluster is running, Dex is running and we have an app at GitHub. There are two missing pieces: * The kube-apiserver needs to be reconfigured to enable OIDC logins. Kubermatic KubeOne will take care of that for us. * We need a way to generate OIDC tokens, so that we can use `kubectl` to interact with the cluster. There are a number of tools available for this, but for this article we chose `kubelogin`, a plugin for `kubectl`. [kubelogin](https://github.com/int128/kubelogin) can be installed via [Krew](https://krew.sigs.k8s.io/) or by simply downloading the binary and making it available anywhere in your system's `PATH`. Choose whatever method you like. Once the plugin is installed, it will offer a few new commands, most importantly `setup` and `get-token`. `setup` can not just be used to set things up, but is also super useful for testing things out. What we want to achieve is that `kubectl` automatically runs kubelogin, which in turn will take care of getting a token from Dex, which will eventually redirect the user to GitHub. As the OIDC token is cached by kubelogin, the login workflow will only happen occasionally. If you have used GKE or EKS, this is similar to how Google's gcloud SDK or Amazon's `aws-iam-authenticator` work. #### Our first Login Let's run the first test and see if kubelogin works. We simulate a login by using the `setup` command like so: ```bash $ kubectl oidc-login setup \ --oidc-issuer-url=https://dex.controlplane.example.com/dex \ --oidc-client-id=<the client ID from the values.yaml here> \ --oidc-client-secret=<the client secret from the values.yaml here> ``` **Important:** Use the ID/secret for the client (most likely called "kubernetes") you defined yourself. This is not the ID/secret that GitHub generated for you. When you run the command above, a browser window should open and Dex will present the login choices to you (note that the KKP login screen is branded by default): ![Dex Login Page Screenshot](/static/dex-oidc-login.jpg) Click on the GitHub link and you will be redirected again. Complete the login at GitHub and you will be redirected to Dex, which will then redirect you back to kubelogin with a temporary code. kubelogin now makes another request to Dex to exchange this temporary code for a JSON Web Token (JWT) and neatly enough, it will then show this token to us: ```bash $ kubectl oidc-login setup ... authentication in progress... ## 2. Verify authentication You got a token with the following claims: { "iss": "https://dex.controlplane.example.com/dex", "sub": "CdY6MjcaOpkSBdd8dGm1Ya", "aud": "kubernetes", "exp": 1607281944, "iat": 1607195544, "nonce": "6Cq8Vz-c-rjGkLjId8Qbr1sYqmxbkROsKcaRTHJHvEI", "at_hash": "qfvZuBmmp8XojkhqIE3AXg" } ## 3. Bind a cluster role Run the following command: kubectl create clusterrolebinding oidc-cluster-admin --clusterrole=cluster-admin --user='https://dex.controlplane.example.com/dex#CdY6MjcaOpkSBdd8dGm1Ya' ... ``` That's pretty cool, but as you can see from step 3 listed in the output above, kubelogin now shows how the username would look like for someone that authenticates via OIDC: `https://dex.controlplane.example.com/dex#CdY6MjcaOpkSBdd8dGm1Ya` -- this is certainly not a memorable identifier and I pity the soul who has to maintain these IDs in a cluster. The issue stems from the fact that by default, Kubernetes uses the "Subject" field (`sub`) for identification. This is because this field is guaranteed to be unique and cannot be changed (you cannot change your own internal ID on GitHub, for example, but you _can_ rename yourself). It is possible to reconfigure the kube-apiserver to use a different field, but which? There is nothing in the token that can meaningfully serve as user identification. This is where scopes come into play. #### Scopes It's important to remember that from Kubernetes/kubelogin's perspective, the OIDC provider is _Dex_, not GitHub. So whatever scope we configure in Kubernetes, _Dex_ needs to understand it and it has absolutely nothing to do with the scopes from GitHub. The [Dex documentation](https://dexidp.io/docs/custom-scopes-claims-clients/) lists the scopes Dex understands. By default, kubelogin uses only the `openid` scope. However, we want `groups` and `profile` as well, which will give us team associations and the GitHub username. Let's try the login again, but with the additional scopes (note the additional fourth CLI flag): ```bash $ kubectl oidc-login setup \ --oidc-issuer-url=https://dex.controlplane.example.com/dex \ --oidc-client-id=<the client ID from the values.yaml here> \ --oidc-client-secret=<the client secret from the values.yaml here> \ --oidc-extra-scope=groups,profile authentication in progress... ## 2. Verify authentication You got a token with the following claims: { "iss": "https://dex.controlplane.example.com/dex", "sub": "CdY6MjcaOpkSBdd8dGm1Ya", "aud": "kubernetes", "exp": 1607281944, "iat": 1607195544, "nonce": "6Cq8Vz-c-rjGkLjId8Qbr1sYqmxbkROsKcaRTHJHvEI", "at_hash": "qfvZuBmmp8XojkhqIE3AXg" "groups": [ "kubermatic:sig-app-management", "kubermatic:sig-cluster-management" ], "name": "Christoph Mewes", "preferred_username": "xrstf" } ... ``` Now, Dex reveals more information from the user identity it received from GitHub. We can now use `preferred_username` to identify users instead of their ID, and make use of the groups as well. ### Kubernetes OIDC It's finally time to enable OIDC logins in Kubernetes. As mentioned previously, Kubermatic KubeOne does all the heavy lifting for us already, so the configuration is minimal: ```yaml apiVersion: kubeone.io/v1beta1 kind: KubeOneCluster versions: kubernetes: '1.19.3' cloudProvider: hetzner: {} external: true features: openidConnect: enable: true config: # The URL of the OpenID issuer, only HTTPS scheme will be accepted. If # set, it will be used to verify the OIDC JSON Web Token (JWT). issuerUrl: "https://dex.controlplane.example.com/dex" # Remember the ID we defined for the client in Dex? This is where it needs to # be put. It defaults to "kubernetes". clientId: "kubernetes" # This is the important piece. By default this is "sub", as it is the most secure. # In our cluster we rely on GitHub usernames being unique and stable enough, so we # switch to `preferred_username`. usernameClaim: "preferred_username" # The remaining fields are just the defaults from KubeOne and noted here just FYI # =============================================================================== # If provided, all usernames will be prefixed with this value. If not # provided, username claims other than 'email' are prefixed by the issuer # URL to avoid clashes. To skip any prefixing, provide the value '-'. usernamePrefix: "oidc:" # If provided, the name of a custom OpenID Connect claim for specifying # user groups. The claim value is expected to be a string or array of # strings. This flag is experimental in kubernetes, please see the # kubernetes authentication documentation for further details. groupsClaim: "groups" # If provided, all groups will be prefixed with this value to prevent # conflicts with other authentication strategies. groupsPrefix: "oidc:" ``` We can update the cluster by running KK1 again. **Important:** Whenever you change a `feature`, you must perform a `--full-upgrade`! ```bash $ kubeone apply --manifest kubeone.yaml --tfjson output.json --force-upgrade ``` The cluster is now ready to accept and validate tokens. Let's create a kubeconfig. ### kubeconfig Start with the kubeconfig given by Kubermatic KubeOne, `example-kubeconfig`. We're going to replace the default context and user and instead inject our own context and configure kubectl to execute the kubelogin plugin. You will notice the similarity in the CLI flags from the `setup` command: ```bash $ cp example-kubeconfig oidc-kubeconfig (remove contexts, users) ``` Insert the following into the `oidc-kubeconfig` ```yaml contexts: # A new context that will use our oidc user when accessing the `example` cluster. - context: cluster: example user: me-via-oidc name: default-context users: # Our new virtual user account. - name: me-via-oidc user: exec: apiVersion: client.authentication.k8s.io/v1beta1 command: kubectl args: - oidc-login - get-token - --oidc-issuer-url=https://dex.controlplane.example.com/dex - --oidc-client-id=<the client ID from the values.yaml here> - --oidc-client-secret=<the client secret from the values.yaml here> - --oidc-extra-scope=groups,profile ``` Save it, set it as your `$KUBECONFIG` and test it out: ```bash $ export KUBECONFIG=oidc-kubeconfig $ kubectl get ns error: You must be logged in to the server (Unauthorized) ``` There is always something more, isn't there? ### RBAC As a final step, we need to grant permissions. We can do this for individual users (called `oidc:<github username>`, e.g. `oidc:xrstf`) or based on teams (identified by `oidc:<org>:<team>`, e.g. `oidc:exampleorg:infra-team`). Let's make everyone from the infra-team an admin: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: infra-team-is-cluster-admin roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: "oidc:exampleorg:infra-team" ``` Apply this using the `example-kubeconfig` and now you will have access: ```bash $ export KUBECONFIG=example-kubeconfig $ kubectl apply --filename rbac.yaml $ export KUBECONFIG=oidc-kubeconfig $ kubectl get ns NAME STATUS AGE cert-manager Active 2h default Active 2h dex Active 2h kube-node-lease Active 2h kube-public Active 2h kube-system Active 2h nginx-ingress Active 2h ``` ### Audit Logging Now that we have readable user identifiers, audit logging makes much more sense. Let's enable it. Once again, KK1 does all the work for us: ```yaml apiVersion: kubeone.io/v1beta1 kind: KubeOneCluster versions: kubernetes: '1.19.3' cloudProvider: hetzner: {} external: true features: # For demo purposes, static audit logging is enough. This will simply make # each kube-apiserver Pod write a JSON file on the node it is running on. # For a production setup, either dynamic audit logging or a log shipper # like fluentd should be used. staticAuditLog: enable: true config: # You _must_ define a policy. This file needs to exist on your local # disk and KubeOne will take care of uploading it to all controlplane # nodes and automatically set up mounts for the kube-apiserver Pods. policyFilePath: audit-policy.yaml openidConnect: enable: true config: issuerUrl: "https://dex.controlplane.example.com/dex" clientId: "kubernetes" usernameClaim: "preferred_username" ``` You can take the example AuditPolicy from the [Kubernetes documentation](https://kubernetes.io/docs/tasks/debug-application-cluster/audit/#audit-policy) as a starting point. Let's run KK1 again (and remember to do a full upgrade, as we once again changed features): ```bash $ kubeone apply --manifest kubeone.yaml --tfjson output.json --force-upgrade ``` Once done, we can check that the audit log is working by SSH'ing onto one of the controlplane nodes and checking `/var/log/kubernetes/audit.log`. If you then use your `oidc-kubeconfig` and are lucky that you are on the node that processed the request, you can find entries like this in the audit log (formatted for better readability): ```json { "kind": "Event", "apiVersion": "audit.k8s.io/v1", "level": "RequestResponse", "auditID": "0c3X90aa-5R41-410S-8eT7-b617c012635F", "stage": "ResponseComplete", "requestURI": "/api/v1/namespaces/kube-system/pods?limit=500", "verb": "list", "user": { "username": "oidc:xrstf", "groups": [ "oidc:kubermatic:infra-team", "oidc:kubermatic:cleanup-team", "system:authenticated" ] }, "sourceIPs": [ "192.168.0.2" ], "userAgent": "kubectl.bin/v1.19.2 (linux/amd64) kubernetes/f574309", "objectRef": { "resource": "pods", "namespace": "kube-system", "apiVersion": "v1" }, "responseStatus": { "metadata": {}, "code": 200 } } ``` And we can see: Username and groups are available, just as planned. We can now go ahead and distribute the `oidc-kubeconfig` among team members and let all of them authenticate this way. :-) ## Conclusion Setting up OIDC is easy, if you know what you're doing. Otherwise you might wrangle with Dex a bit until you understand which scope scopes which claim and who claims what and when. As we will be granting permissions solely on groups (i.e. GitHub teams), it's not important for us that the GitHub username can potentially change. The user is mostly informational in the audit log. kubelogin deserves a special mention, as it made the integration very smooth. The `setup` command is super helpful when debugging JWT claims, so we used the command much more for testing than for setting things up. Maybe `debug` or `simulate` would have been better names for the command. ## Learn More * [Product Page](https://www.kubermatic.com/products/kubermatic-kubeone/) * [Product Demo](https://www.kubermatic.com/resources/demo-deploy-and-manage-your-cluster-everywhere-with-kubeone/) * [Contact Us](https://www.kubermatic.com/contact-us/) * [Documentation](https://docs.kubermatic.com/kubeone/v1.0/) * [Find Kubermatic KubeOne on Github](https://github.com/kubermatic/kubeone) --- ## Run Amazon EKS Distro With Kubermatic KubeOne - **URL:** https://www.kubermatic.com/blog/run-amazon-eks-distro-with-kubeone/ - **Date:** 2026-05-07 - **Description:** Install EKS Distro on AWS and Amazon Linux 2 with Kubermatic’s open source cluster lifecycle management tool Kubermatic KubeOne. - **Categories:** Products, Community - **Tags:** KubeOne, Open Source Projects - **Authors:** Kristin Wittig Today [Amazon announced Amazon EKS Distro](https://aws.amazon.com/de/blogs/opensource/introducing-amazon-eks-distro/) (EKS-D), a Kubernetes distribution based on and used by Amazon EKS. Amazon EKS Distro enables you, as an infrastructure responsible, to create reliable and secure Kubernetes clusters using the same versions of Kubernetes and its dependencies deployed by Amazon EKS. Each Amazon EKS Distro release follows the [EKS process](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html#kubernetes-release-calendar), verifying new Kubernetes versions for compatibility.  The EKS Distro source code, open source tooling, binaries and container images, as well as configuration, are provided for reproducible builds via public Git and S3 storage locations. With EKS-D, Amazon provides extended support for Kubernetes versions after community support expires, offering updated builds of previous versions including the latest security patches. As an AWS partner, we are proud that Kubermatic KubeOne is part of the first batch of distributions to offer out-of-the-box support for Amazon EKS Distro. Kubermatic KubeOne is an infrastructure-agonistic and open source Kubernetes cluster lifecycle management tool that automates the deployment and Day 2 operations of single Kubernetes clusters. Thanks to Kubermatic KubeOne’s Terraform integration and ease of use, users can install EKS-D on AWS and Amazon Linux 2 with minimal operational effort.   In the future, we will extend support to on-prem environments, bringing the advantages of EKS-D to the data centers. Moreover, we are working on adding EKS-D support for other Linux distributions (Ubuntu, CentOS, Flatcar) and ensuring you can use EKS-D on all other providers that are natively supported by Kubermatic KubeOne (i.a. OpenStack, VMware vSphere).  In our [technical blog post](/blog/get-started-with-eks-d-at-the-speed-of-light-with-kubermatic-kubeone/) you can find a detailed description of how to set up EKS Distro with Kubermatic KubeOne. If you would like to learn more about Amazon EKS Distro on Kubermatic KubeOne, feel free to [contact us](/contact-us/).  ### Learn More * Find Kubermatic KubeOne on [Github](https://github.com/kubermatic/kubeone) * See Kubermatic [KubeOne Demo](/resources/demo-deploy-and-manage-your-cluster-everywhere-with-kubeone/)  * Read [technical blog post](/blog/get-started-with-eks-d-at-the-speed-of-light-with-kubermatic-kubeone/) on EKS-D with Kubermatic KubeOne --- ## Get Started With EKS-D: Kubermatic KubeOne - **URL:** https://www.kubermatic.com/blog/get-started-with-eks-d-at-the-speed-of-light-with-kubermatic-kubeone/ - **Date:** 2026-05-07 - **Description:** In this blog post you learn how to get started with Amazon EKS Distro on Kubermatic KubeOne - **Categories:** Products, Community - **Tags:** KubeOne, Open Source Projects - **Authors:** Marko Mudrinić Today Amazon announced [Amazon EKS Distro](https://aws.amazon.com/blogs/opensource/introducing-amazon-eks-distro/) (EKS-D), a Kubernetes distribution based on and used by Amazon EKS. Amazon EKS Distro enables operators to create reliable and secure Kubernetes clusters using the same versions of Kubernetes and its dependencies deployed by Amazon EKS. As an AWS partner, we are proud that our open source cluster lifecycle management tool Kubermatic KubeOne is part of the first batch of distributions to offer out-of-the-box support for Amazon EKS Distro. Thanks to Kubermatic KubeOne’s Terraform integration and ease of use, users can install EKS Distro on AWS and Amazon Linux 2 with minimal operational effort.   In this blog post, we provide you with a step by step description of how to get started with Amazon EKS Distro on Kubermatic KubeOne.  ### Prerequisites Before setting up Amazon EKS Distro, you need to install Kubermatic KubeOne v1.2.0-alpha.0 by downloading a binary from the [Github releases](https://github.com/kubermatic/kubeone/releases/tag/v1.2.0-alpha.0) and following the instructions in our [documentation](https://docs.kubermatic.com/kubeone/v1.0/). Moreover, make sure that you have the following prerequisites satisfied:  * Installed Terraform v0.12+ if you want to provision the infrastructure using our [example Terraform configs](https://docs.kubermatic.com/kubeone/v1.0/concepts/#example-terraform-configs). You can find the installation instructions in the [official Terraform docs](https://learn.hashicorp.com/terraform/getting-started/install.html) * The AWS credentials configured. We recommend configuring environment variables by following the [Configuring Credentials](https://docs.kubermatic.com/kubeone/v1.0/prerequisites/credentials/) guide * An SSH key and the `ssh-agent` configured as described in the [Configuring SSH](https://docs.kubermatic.com/kubeone/v1.0/prerequisites/ssh/) document Once you are all set with this, we can continue by creating the infrastructure where the Amazon EKS Distro cluster will be provisioned. ### Create the Infrastructure **Step 1** To make it easier to get started, we provide example Terraform configs for AWS that you can use to create the infrastructure. Along with the Kubematic KubeOne binary, you can find the `example` directory that contains the example configs. Explore the AWS configs by navigating to the `./examples/terraform/aws` directory. **Step 2** Initialize Terraform by running the `init`  command.  ```bash terraform init ``` **Step 3**  Now, it’s time to configure the variables. Create the `terraform.tfvars` file to instruct Terraform to create Amazon Linux 2 instances and to use the static workers instead of MachineDeployments.  Here is an example `terraform.tfvars` file: ```bash cluster_name = "<replace-with-cluster-name>" # Currently, machine-controller doesn’t support Amazon Linux 2, so we will # use KubeOne Static Worker nodes. The static worker nodes are managed # by KubeOne, Terraform, and kubeadm, and are defined by the # static_workers_count variable below. initial_machinedeployment_replicas = 0 # This variable doesn't have any effect, as initial_machinedeployment_replicas # is set to 0. Instead, static worker nodes running Amazon Linux 2 will be used # (defined by static_workers_count and os variables). # This is required in order for validation to pass and will be fixed in # the upcoming versions. worker_os = "ubuntu" # Number of worker nodes to be created and provisioned. static_workers_count = 3 # Currently, KubeOne supports EKS-D only on Amazon Linux 2. # Support for other operating systems is planned for the future. os = "amazon_linux2" ssh_username = "ec2-user" bastion_user = "ec2-user" ``` **Step 4** With the variables configured, you’re now ready to create the infrastructure by applying the configs. You can see what changes will be made by running the `plan` command: ```bash terraform plan ``` If you agree with the proposed changes, run the `apply` command to create the infrastructure. You’ll be asked to type `yes` to confirm your intention. ```bash terraform apply ``` It takes several minutes to provision the infrastructure and for instances to come up. **Step 5** The last step regarding provisioning infrastructure is to export the Terraform state to be parsed by the Kubermatic KubeOne Terraform Integration for information about instances and worker nodes. The state file is generated using the `terraform output` command. ```bash terraform output -json > tf.json ``` **Note:** For more information on the Kubermatic KubeOne Terraform integration and exporting the Terraform State please consult our [documentation](https://docs.kubermatic.com/kubeone/v1.0/infrastructure/terraform_integration/). ### Provisioning **Creating the KubeOne Configuration Manifest** Kubermatic KubeOne declares clusters declaratively using the KubeOne Configuration Manifest. The first step in the provisioning process is to create the manifest and define the cluster that’s going to be provisioned.  Create a file called `kubeone.yaml` that will define the following properties: * The desired Kubernetes version in the EKS-D format, e.g. `v1.18.9-eks-1-18-1` * The target cloud provider (in our case AWS) * The asset configuration containing references to EKS-D images and binaries Other information, such as information about the control plane and worker instances to be used, and information about the API server load balancer, are taken from the Terraform output generated in the previous step. Here's an example: ```bash apiVersion: kubeone.io/v1beta1 kind: KubeOneCluster versions: kubernetes: "<kube-apiserver-tag>" cloudProvider: aws: {} assetConfiguration: kubernetes: imageRepository: "public.ecr.aws/eks-distro/kubernetes" pause: imageRepository: "public.ecr.aws/eks-distro/kubernetes" imageTag: "<pause-image-tag>" etcd: imageRepository: "public.ecr.aws/eks-distro/etcd-io" imageTag: "<etcd-image-tag>" coreDNS: imageRepository: "public.ecr.aws/eks-distro/coredns" imageTag: "<coredns-image-tag>" metricsServer: imageRepository: "public.ecr.aws/eks-distro/kubernetes-sigs" imageTag: "<metrics-server-image-tag>" cni: url: "<cni-plugins-url>" nodeBinaries: url: "<node-binaries-url>" kubectl: url: "<kubectl-binary-url>" ``` Make sure to replace the placeholder values (values with <>) with the real values. You can find the real values in the EKS-D Release Manifest for the release you want to deploy.  Find the entries with the following descriptions, note the image’s tag, and replace the placeholder value in the KubeOne manifest with the image’s tag: * “kube-apiserver container image” - replace placeholder `<kube-apiserver-tag>` (example value `v1.18.9-eks-1-18-1`) * “pause container image” - replace placeholder `<pause-image-tag>` (example value `v1.18.9-eks-1-18-1`) * “etcd container image” - replace placeholder `<etcd-image-tag>` (example value `v3.4.14-eks-1-18-1`) * “coredns container image” - replace placeholder `<coredns-image-tag>` (example value `v1.7.0-eks-1-18-1`) * “metrics-server container image” - replace placeholder `<metrics-server-image-tag>` (example value `v0.4.0-eks-1-18-1`) Once done, find the entries with the following descriptions, note the artifact’s URI (from the `archive.uri` field), and replace the following placeholder value in the KubeOne manifest with the URI. Make sure to choose the artifact for the correct architecture (by default `amd64`). * “cni-plugins tarball for linux/amd64” - replace placeholder `<cni-plugins-url>` (example value `https://distro.eks.amazonaws.com/kubernetes-1-18/releases/1/artifacts/plugins/v0.8.7/cni-plugins-linux-amd64-v0.8.7.tar.gz`) * “Kubernetes node tarball for linux/amd64” - replace placeholder `<node-binaries-url>` (example value `https://distro.eks.amazonaws.com/kubernetes-1-18/releases/1/artifacts/kubernetes/v1.18.9/kubernetes-node-linux-amd64.tar.gz`) * “kubectl binary for linux/amd64” - replace placeholder `<kubectl-binary-url>` (example value `https://distro.eks.amazonaws.com/kubernetes-1-18/releases/1/artifacts/kubernetes/v1.18.9/bin/linux/amd64/kubectl`) **Provisioning the Cluster** With the configuration manifest in place, you’re ready to provision the cluster. The cluster is provisioned by running the appropriate `kubeone apply` command, and providing it the configuration manifest and the exported Terraform state file. ```bash kubeone apply --manifest kubeone.yaml -t tf.json ``` The `apply` command analyzes the given instances, verifies that there is no Kubernetes running on those instances, and offers you to provision the cluster. You’ll be asked to confirm your intention to provision the cluster by typing `yes`. ![EKS-D_Screenshot 1](/static/blog-image_1.png) After confirming your intention to provision the cluster, the process will start. It usually takes 5-10 minutes for the cluster to be provisioned. Meanwhile, you can configure the cluster access. ### Configuring the Cluster Access Kubermatic KubeOne automatically downloads the Kubeconfig file for the cluster. It’s named as `<cluster_name>-kubeconfig`, where `<cluster_name>` is the name provided in the `terraform.tfvars` file. You can use it with kubectl such as: ```bash kubectl --kubeconfig=<cluster_name>-kubeconfig ``` or export the `KUBECONFIG` environment variable: ```bash export KUBECONFIG=$PWD/<cluster_name>-kubeconfig ``` You can check the [Configure Access To Multiple Clusters](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) document to learn more about managing access to your clusters. Finally, to test if everything works properly, you can try to get nodes and verify that worker nodes joined a cluster and that all nodes are ready. ```bash kubectl get nodes ``` You now should see the number of nodes defined in the `terraform.tfvars` file along with the control plane nodes. ![EKS with KubeOne_Screenshot](/static/eks-d_screenshot-2.png) That’s it - you run your first Amazon EKS Distro Cluster:) Congratulations!  ### What Is Next? We are currently working on extending support to on-prem environments, bringing the advantages of EKS Distro to the data centers. Moreover, we will be adding EKS distro support for other Linux distributions (Ubuntu, CentOS, Flatcar), as well as ensuring you can use EKS Distro on all other providers that are natively supported by Kubermatic KubeOne (i.a. OpenStack, VMware vSphere). If you would like to know more about Amazon EKS Distro on Kubermatic KubeOne, feel free to [contact us](https://www.kubermatic.com/contact-us/).  ### Learn More * Find Kubermatic KubeOne on [Github](https://github.com/kubermatic/kubeone) * See Demo: [Set up EKS-Distro With Kubermatic KubeOne](https://www.kubermatic.com/resources/demo-get-started-with-eks-distro-in-less-than-5-minutes/) * Read [AWS Announcement Post](https://aws.amazon.com/de/blogs/opensource/introducing-amazon-eks-distro/) --- ## Docker Rate Limit Mitigation with Kubermatic - **URL:** https://www.kubermatic.com/blog/how-to-mitigate-the-impact-of-docker-rate-limits-with-kubermatic/ - **Date:** 2026-05-07 - **Description:** How to set up a Registry Mirror with Kubermatic Kubernetes Platform to mitigate the risk from Docker rate limits. - **Categories:** Products - **Tags:** KKP, KubeOne - **Authors:** Sascha Haase If you are using Docker Hub, you will be aware of [pull-request limits](https://docs.docker.com/docker-hub/download-rate-limit/) that are being enforced since November 2. Limits are determined based on the account type: If you are using the free tier of Docker Hub, you can only execute 100 pulls per 6 hours and per client IP for anonymous clients. Authenticated users are limited to 200 pulls within the same time frame.  From a user perspective, it is hard to predict if and when these limits will be reached. Since many CI/CD systems are using anonymous pulls, this yields the risk of unpredicted outages on random new pulled containers when the limit is reached.  With our products Kubermatic Kubernetes Platform (KKP) and Kubermatic KubeOne, users can easily mitigate the risk by setting up a Registry Mirror. In this blog post, we explain how to. But before we start, let’s first take a look at what a pull actually means. ## What Is a Pull? According to [Docker](https://docs.docker.com/docker-hub/download-rate-limit/), pulls are defined as the following: * A pull request is defined as up to two GET requests on registry manifest URLs (/v2/\*/manifests/\*) * A normal image pull makes a single manifest request * A pull request for a multi-arch image makes two manifest requests * HEAD requests are not counted * Limits are applied based on the user doing the pull, and not based on the image being pulled or its owner ## Mitigate the Risk With Registry Mirroring To avoid any problems with the Docker Hub rate limits, we recommend setting up an internal registry mirror that can be used by Kubermatic Kubernetes Platform and Kubermatic KubeOne. Example enterprise-ready registries are [Harbour](https://goharbor.io/) or [Jfrog Artifactory](https://jfrog.com/artifactory/start-free/)  ### Example Registry Mirror Kubermatic Kubernetes Platform (KKP) contains an image-loader utility that can be used to collect and mirror all Docker images used by KKP. The utility works by faking the reconciliation and then checking the created Deployments/DaemonSets/… for the referenced images. A simple example use would be: ```bash ./image-loader -registry my.local.registry:5000 ``` This will go through all reconciling functions as well as all addons to collect the Docker images. **Note:** This does not include Helm charts, so Grafana for example will not be included here. Helm charts are handled differently. For these, we currently have a helper script for our own offline test setup. This script renders all Helm charts, parses the YAML for Docker image references and then does what the image-loader did, basically: pull, retag, push to another registry.  An example on how to use it: ```bash export TARGET_REGISTRY=my.registry.local:5000 helm template charts/cert-manager | ./hack/retag-images.sh helm template charts/nginx-ingress-controller | \ ./hack/retag-images.sh helm template charts/oauth | ./hack/retag-images.sh ``` Care must be taken to run the helm-template with the same values as the YAML file.  Otherwise, as the YAML file is later used to install the charts, the process could accidentally miss some images (e.g. Thanos images as Thanos is not enabled by default in Prometheus). It is then necessary to configure all Helm charts to use these newly mirrored images. For Grafana this could look like this: ```yaml grafana: image: repository: "my.registry.local:5000/grafana/grafana" utilImage: repository: "my.registry.local:5000/kubermatic/util" ``` ## Registry Configuration with Kubermatic Kubernetes Platform KKP can be configured with an `overwriteRegistry` flag (in the `KubermaticConfiguration` CRD). This flag contains the host/port of the Docker registry to use for all images used on the seed (i.e. inside the user cluster control plane namespace). Additionally, this registry is also used for the Container Linux Update Operator running inside the user cluster. The flag cannot be used to overwrite more than the host, so `docker.io/grafana/grafana` becomes `myregistry.corp.local/grafana/grafana`, but the path part (`/grafana/grafana`) cannot be changed. Likewise, it’s also not possible to have different overwrites per registry (i.e. users cannot overwrite docker.io but leave quay.io intact). ## Registry Configuration With Kubermatic KubeOne Kubermatic KubeOne can be configured with the RegistryConfiguration API. The RegistryConfiguration API  allows users to override the registry configuration. The API is similar to KKP, but allows for more flexibility. Settings specified in the RegistryConfiguration can be applied to all components deployed by Kubermatic KubeOne and to kubeadm. ```go type RegistryConfiguration struct { OverrideRegistry string `json:"overrideRegistry,omitempty"` OverrideRegistryOrg bool `json:"overrideRegistryOrg,omitempty"` OverrideRegistryIgnore []string `json:"overrideRegistryIgnore,omitempty"` } ``` The OverrideRegistry provides the same functionality as in KKP. The OverrideRegistryOrg allows users to enable overriding the organization/user (e.g. `/calico/cni` could be changed to `/custom-mirror/cni`). The OverrideRegistryIgnore slice can be used to specify registries to be ignored (e.g. if user provider `k8s.gcr.io` and `quay.io`, those registries would be used instead of registry provided in the OverrideRegistry field). ## Learn More * [Documentation](https://docs.kubermatic.com/kubermatic/v2.15/) for Kubermatic Kubernetes Platform * [Documentation](https://docs.kubermatic.com/kubeone/v1.0/) for Kubermatic KubeOne * About [Docker Rate Limits](https://www.docker.com/pricing) --- ## Kubernetes Operators: Automating Complex App Lifecycles - **URL:** https://www.kubermatic.com/blog/kubernetes-operators-automating-complex-application-lifecycles/ - **Date:** 2026-05-07 - **Description:** Learn why K8s Operators are important to automating a complex, stateful application, how Operators work, and best practices for writing your own Operators. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Sascha Haase ## What Is a Kubernetes Operator? Kubernetes Operators are a way to package, deploy, and manage Kubernetes applications. This includes Kubernetes applications deployed on Kubernetes and those that are managed using the Kubernetes API or kubectl. A Kubernetes Operator is a controller specific to an application, which extends the Kubernetes API, letting you generate and manage instances of a complex application. It builds on the concept of a resource and controller in Kubernetes, but adds domain-specific information that can help you fully automate the lifecycle of the application. In this article, you will learn: * Why are Kubernetes Operators Important? * How Does a Kubernetes Operator Work? * Kubernetes Operator Example * Best Practices for Writing Kubernetes Operators * Use the Operator SDK * Keep Reconcile Functions Clean * Modify One Custom Resource at a Time ## Why are Kubernetes Operators Important? In a typical use case, Kubernetes manages **stateless applications**, such as web servers, without requiring in-depth knowledge of their workings. Here, operators are not needed.  However, **stateful applications** such as databases and monitoring systems require domain-specific knowledge that the standard Kubernetes tooling does not possess. You need to add this information to scale, update and dynamically reconfigure these applications, including compute, [storage](https://cloud.netapp.com/blog/cvo-blg-kubernetes-storage-an-in-depth-look), and networking resources.  Kubernetes operators can manage and automate the lifecycle of a stateful application by adding this domain specific knowledge into Kubernetes extensions. Kubernetes operators can standardize complex processes, making them scalable and repeatable, and eliminating tedious manual management tasks.  ## How Does a Kubernetes Operator Work? Operators are application-specific controls. They represent an extension of the Kubernetes API that lets you build, configure and manage complex application lifecycles, typically for operations or site reliability teams. Operators use controllers to see the behavior of objects in the Kubernetes environment. These are a bit different from regular controllers, because they track custom objects, also known as custom resources (CRs). A CR is another extension of the Kubernetes API, which lets you store structured data that represents a desired application state. ![How a Kubernetes Operator works](/static/operator-blog-post.png) Operators continuously track cluster events related to certain types of custom resources. An operator can track add, update, or delete events. When the operator sees changes in the environment, actions are taken in the custom controller to bring the Kubernetes cluster or external system to the desired state (this is known as the “reconciliation loop”). ## Kubernetes Operator Example etcd is a core Kubernetes component that stores cluster configuration. It is managed by the Etcd Cluster Operator (see [source code](https://github.com/improbable-eng/etcd-cluster-operator) on Github), an Operator used to automatically create and manage etcd instances in Kubernetes.  The Etcd Cluster Operator provides an API based on custom resource definitions (CRDs), letting you use Kubernetes resources to define etcd clusters and manage them using Kubernetes native tools. etcd is a distributed key-value data store, which achieves high availability using the following rules: * Each etcd instance has a separate failure domain for computing, storage, and networking * Each instance of etcd has a unique name on the network * Any instance of etcd can access any other instance on the network * Each instance of etcd is able to discover all other instances In addition to these rules, scaling up or down in an etcd cluster requires certain actions, and before adding/removing instances, it needs to post changes to the cluster using the etcd management API. [Data backups](https://cloudian.com/guides/backup-cloud-storage/data-backup-in-depth/) are done using the "snapshot" endpoint, provided by the etcd management API, which streams a backup file when it is accessed. To restore from backup, a tool called etcdctl is provided as part of the backup file, and in the data directory of each etcd host.  As you can see, this management is outside the scope of a regular StatefulSet. This is the type of complex, automated functionality that an Operator can provide. ## Best Practices for Writing Kubernetes Operators ### Use the Operator SDK While you can code Operators by hand, Kubernetes provides an Operator SDK that can be used to quickly create a new operator, with boilerplate code and YAML configuration. It also provides a useful Reconcile function for custom resources the Operator needs to manage. This function is similar to a main function on a regular software component.  It is a good idea to consistently use the Operator SDK, so you can more easily collaborate when committing code to several Operators, and to create a smooth learning curve for developers working on Operators. Once a developer has used the Operator SDK, it will be easier to work with any Operator created using the SDK. ### Keep Reconcile Functions Clean When using the Reconcile function, there are several possible return codes, each resulting in specific Operator behavior. The Operator watches the return values of the Reconcile function and may either continue the reconcile loop, delay it, or end the loop.  It may seem convenient to add business logic to the Reconcile function, but this can interfere with the core functioning of the Operator. Keep Reconcile functions clean to make it easy to determine what will be the output of the function. Or if you do add business logic, make sure you consistently return the same output values, allowing the operator to correctly maintain the reconcile loop. ### Modify One Custom Resource at a Time Whenever a custom resource changes, whether because of a user action or because of something you did in the Reconcile function or a subroutine, the reconcile loop runs again. For example, if you need to update the ID of a resource, the reconcile loop will run again with the updated version of the resource. This means that changing multiple custom resources can cause race conditions—if there is parallel processing, there could be multiple simultaneous requests to the same resource in a single line of your code. Or even if requests are not parallel, numerous successive changes to the same operator can make the Operator extremely busy. To prevent this, modify resources with care. ## Kubernetes Operators with Kubermatic At Kubermatic, we extend the Operators paradigm beyond applications to manage the clusters themselves. With our open source [Kubermatic Kubernetes Platform](https://www.kubermatic.com/products/kubermatic-kubernetes-platform/), we are using Kubernetes to manage Kubernetes. On a technical level, the cluster state is defined in Custom Resource Definitions then stored within etcd. A set of controllers and their associated reconciliation loops watch for changes or additions to the cluster state and update each as required. All state is stored in a “Master Cluster”. When a new user cluster is defined, the control plane components (API server, etcd, Scheduler, and Controller-Manager) are created as a deployment of containers within a namespace of the master cluster. The worker nodes of the user cluster are deployed by [machine-controller](https://github.com/kubermatic/machine-controller) which implements [Cluster API](https://github.com/kubernetes-sigs/cluster-api) to bring declarative creation, configuration, and management to worker nodes.  Operators allow Kubermatic Kubernetes Platform to automate not only the creation of clusters, but also their full life cycle management. Thanks to its specific architecture, KKP can be used to manage tens of thousands of clusters with minimal operational effort. If you like to learn more about Kubermatic Kubernetes Platform, feel free to [reach out](https://www.kubermatic.com/contact-us/) or [find us on Github](https://github.com/kubermatic/kubermatic). --- ## Deploy and Manage Your Cluster Everywhere With KubeOne - **URL:** https://www.kubermatic.com/resources/demo-deploy-and-manage-your-cluster-everywhere-with-kubeone/ - **Date:** 2022-12-01 - **Description:** Learn more about how to automate cluster operations on your cloud, on-prem, edge and IoT environments with KubeOne. # Deploy and Manage Your Cluster Everywhere With KubeOne ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch the demo and start your cloud native future with KubeOne today. **Deploy and Manage Your Cluster Everywhere With KubeOne** - KubeOne is an [**open source cluster lifecycle management tool**](https://github.com/kubermatic/kubeone) for single Kubernetes clusters - It automates the deployment and Day 2 operations of Highly Available clusters to make your life easier everywhere: KubeOne works in the cloud, the datacenter, as well as in edge and IoT environments. - Features: 1. Complete Cluster Reconciliation Using a Single Command 2. KubeOneCluster API Promoted to Beta 3. Static Worker Nodes Support for Bare-metal, IoT, and Edge Environments 4. Deploy the CNI Plugin of Your Choice 5. Extended OS Support With Flatcar, CentOS 8, and RHEL - Check out [**KubeOne 1.1**](/blog/kubeone-1-1-is-ga/) and its new features ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## How to Migrate 100 Clusters Between Clouds Without Downtime? - **URL:** https://www.kubermatic.com/resources/how-to-migrate-100-clusters-between-clouds-without-downtime/ - **Date:** 2022-12-01 - **Description:** Learn more about the current state of the technical concept, known problems and insides of the already proven migration steps for stateless workload. # A Future Journey: How to Migrate 100 Clusters Between Clouds Without Downtime? ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch the talk and join us on an interactive journey to discover the main challenges of live migration at scale. Have you ever thought about migrating your Kubernetes clusters to another cloud provider to save costs? Yes? Us too! Join us on an interactive journey to discover the main challenges of live migration at scale of etcd’s, traffic routing and application workloads from one cloud to another. The talk will discuss the current state of the technical concept, known problems and insides of the already proven migration steps for stateless workload. As part of the journey, we’ll see the differences between migrating one or one hundred clusters with productive workloads; What parts can be automated? What steps may need to be manual? Let’s see how an automated solution could look like in the future and what steps are missing. Speaker: Tobias Schneck, Senior Software Engineer @ Kubermatic & Manuel Stößel, Systems Architect/Team Lead @ Kubermatic ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## High Performance KubeVirt in Action - **URL:** https://www.kubermatic.com/resources/high-performance-kubevirt-in-action/ - **Date:** 2022-12-01 - **Description:** Learn more about the real world solution design of a high performance KubeVirt for running mission critical enterprise workload. # High Performance KubeVirt in Action ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch the talk and learn more about how KubeVirt brings Cloud Native Virtual Machine management to Kubernetes. This talk details a real world solution design of a high performance KubeVirt for running mission critical enterprise workload. KubeVirt brings Cloud Native Virtual Machine management to Kubernetes. It unifies workload orchestration across Containers, Virtual Machine, as well as Serverless. Solution designs around KubeVirt, however, are sparse as of date, especially in networking and storage. On the other hand, workloads running on Virtual Machines often demand high performance and isolation enhancement. In this talk, Red Hat and Kubermatic jointly share with the community their customer engagement experiences of building a high performance KubeVirt environment by integrating with Gardener and multiple CNCF projects, including Kubernetes, KubeVirt, Rook, and Kubernetes Network Plumbing Working Group. Speaker: Marcin Franczyk, Software Engineer @ Kubermatic & Huamin Chen, Senior Principal Software Engineer @ Red Hat ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Ask Us Anything About Operators - **URL:** https://www.kubermatic.com/resources/ask-us-anything-about-operators/ - **Date:** 2022-12-01 - **Description:** Follow the discussion whether Operators are too complex and if GitOps should be used by everyone. # Ask Us Anything About Operators ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch the Discussion and Learn More About Kubernetes Operators From Leading Cloud Native Experts Operations Topics covered: - Operators – too complex to succeed? - Operations automation in general, how far are we away from systems running systems? - Tools, tools, tools – is the tool more important or the usage of it? - GitOps - is it for everyone? - Where are we with Operators one year into the future? **Sascha Haase, VP Edge @ Kubermatic** **Philipp Krenn, Developer Advocate & Community Team Lead @ Elastic** **Ádám Sándor, Cloud Native Architect @ Container Solutions** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## 3 Years of Running Operators in Production – A Reflection - **URL:** https://www.kubermatic.com/resources/3-years-of-running-operators-in-production-a-reflection/ - **Date:** 2024-02-12 - **Description:** Join us for an exciting journey back to when everything started with the idea to build our our first Kubernetes Operator to manage K8s in K8s. # 3 Years of Running Operators in Production – A Reflection ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch the Session and Learn How Operators Help You Automate Daily Operations In 2016, we were driven by the idea to find a generic way to run Kubernetes clusters everywhere. So far so good….but how exactly? Could it make sense to run Kubernetes in Kubernetes? Well, let’s give it a try. This is how we started to build our first Kubernetes Operator to manage Kubernetes in Kubernetes in a scalable way. Early 2017, we first went into production with about a dozen of clusters on AWS. Meanwhile, we manage hundreds of clusters across large-scale multi-cloud deployments. More than three years after the start of this exciting journey, we look back on what we have learned and show how we plan to extend the operator paradigm to the edge. **Sebastian Scheele, CEO & Co-Founder @ Kubermatic** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Using an Operator With a Well-Known Java Application Server - **URL:** https://www.kubermatic.com/resources/using-an-operator-with-a-well-known-java-application-server/ - **Date:** 2022-12-01 - **Description:** Learn more about how to manage overall WebLogic environment through Kubernetes APIs. # Using an Operator With a Well-Known Java Application Server ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch the Session and Learn How Operators Can Help Automate Daily Operations of Your Infrastructure. Containerization of a traditional Java EE Application Server such as WebLogic needs a mind-shift of how applications should be developed an how existing environments can be transformed to a managed Kubernetes Docker platform. To manage a traditional style platform as a WebLogic Application Server requires managing it with “knowledge from the field” and thats why Oracle developed an operator specialized for installing, configuring and operating a WebLogic Server in a Kubernetes Cluster, such as: - Simpler WebLogic management in Kubernetes - Kubernetes resources are allocated for WebLogic domain(s) - Manages overall WebLogic environment through Kubernetes APIs - Load Balancer, Network, - Ingress Controllers, - Security, - HA restart, upgrade, scaling - Persistent storage - Ensurance all best practices are followed The session will tell you all you need to setup an operator such as these, from a commercial product to what it is now , an OpenSource initiative developed and maintained. **Michel Schildmeijer, Solutions Architect @ Qualogy** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Build Your Operator With the Right Tool - **URL:** https://www.kubermatic.com/resources/operatorcon-build-your-operator-with-the-right-tool/ - **Date:** 2022-12-01 - **Description:** See different ways of building Kubernetes Operators and learn more about how the Operator Capability Model affects your toolkit. # Build Your Operator With the Right Tool ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch the Recording and Learn How Kubernetes Operators Are About to Bring Kubernetes to the Next Level of Automation You want to build a Kubernetes Operator for your software. Which tool to choose? Operator SDK with Helm, Ansible, or Go? Or maybe start from scratch with Python, Java, or any other programming language? And what is the right phase in the Operator Capability/Maturity Model that you should provide? In his talk Rafal presents: - Different ways of building Kubernetes Operators - Demo of building the same Operator using different tools - Methods used by the most popular Operators (Couchbase, Prometheus, MongoDB) - Operator Capability Model and how it affects your toolkit - Our journey with Hazelcast Operator **Rafal Leszko, Cloud Software Engineer @ Hazelcast** ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## KubeOne 1.1 is GA! - **URL:** https://www.kubermatic.com/blog/kubeone-1-1-is-ga/ - **Date:** 2026-05-07 - **Description:** The new release adds a cluster autoscaler for optimized resource usage. - **Categories:** Products, Community - **Tags:** KubeOne, Open Source Projects - **Authors:** Sascha Haase As KubeCon + CloudNativeCon North America Virtual kicks off, we are proud to announce general availability of KubeOne 1.1.  KubeOne is our [open source cluster lifecycle management tool](https://github.com/kubermatic/kubeone) for single Kubernetes clusters. It automates the deployment and Day 2 operations of Highly Available clusters for the cloud, the datacenter, and edge and IoT environments. The new release of KubeOne 1.1 adds a cluster autoscaler and the possibility to mirror Docker images onto a private registry. Private registries help organizations ease possible effects resulting from the introduction of [Docker rate limits](https://docs.docker.com/docker-hub/download-rate-limit/). With the new autoscaler, **users can now define the utilization threshold where nodes are automatically added to the cluster.** In addition to removing manual effort, the new feature helps optimize resource usage and costs, while enabling heavy scaling strategies. **Registry Mirroring allows users to easily store all Docker images used for the Kubernetes components onto a private registry.** This increases the stability and the longevity of Kubernetes installations in the light of Docker rate limits. Moreover, the release adds an OverwriteRegistry functionality, with which users can redirect the source for the installation to their private repository. What we have shown above is just a glimpse of how we relentlessly work on improving the user experience of KubeOne. We put continued effort in automating every aspect of Kubernetes operations while giving you the flexibility to work with your infrastructure of choice without vendor-lock in. If you want to learn more about the KubeOne project, check it out on [Github](https://github.com/kubermatic/kubeone) or [contact us](https://www.kubermatic.com/contact-us/) so we can assist you.  **Learn More** * Check out the [Changelog](https://github.com/kubermatic/kubeone/blob/master/CHANGELOG.md) * Watch Webinar: [Meet KubeOne](https://www.kubermatic.com/resources/meet-kubeone-install-configure-upgrade-and-maintain-ha-kubernetes-clusters-anywhere/) --- ## Kubernetes 101 Part 6.2: Keeping the State of Apps - **URL:** https://www.kubermatic.com/resources/kubernetes-101-part-6-2-keeping-the-state-of-apps/ - **Date:** 2022-12-01 - **Description:** Learn how to provide persistent storage in the form of different volumes to the volatile pods. # Keeping the State of Apps Part 2 ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Watch this Epsiode of Our Webinar Series and Get Started With Keeping the State of Apps. In this episode of our Kubernetes 101 series you will learn how to provide persistent storage in the form of different volumes to the volatile pods. This allows containers within pods or all distributed instances in the cluster to have access to the same data. Topics of this session: - How to use simple Volumes inside the Pods? - What types of Volumes are available? - How do PersistentVolumes differ from Volumes? - How and by whom are PersistentVolumes defined? - How and by whom is persistent storage requested via PersistentVolumeClaims? - How do StorageClasses help to make this process more dynamic? ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Introduction to Deployment Strategies - **URL:** https://www.kubermatic.com/blog/introduction-to-deployment-strategies/ - **Date:** 2026-05-07 - **Description:** A Kubernetes Deployment strategy encompasses the methods of creating, upgrading, or downgrading to a different version of a Kubernetes application. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Seyi Ewegbemi The last part of this Kubernetes 101 series focused on ReplicaSets and Deployments and why it is better to use Deployments rather than Pods to manage your Kubernetes applications. In this part of the series, we will walk you through different types of Deployment strategies to give you the insight of their functionalities as well as to know which particular strategy would suit best a specific use case. It is advisable to have prior knowledge of the Kubernetes objects like [Pods](https://www.kubermatic.com/blog/introduction-to-pods/), [Deployments](https://www.kubermatic.com/blog/introduction-to-kubernetes-replicasets/) and [ReplicaSets](https://www.kubermatic.com/blog/introduction-to-kubernetes-replicasets/) to follow the hand-on practice.  ## Deployment Strategies A Kubernetes Deployment strategy encompasses the methods of creating, upgrading, or downgrading to a different version of a Kubernetes application. For those that are familiar with software installation and update on PCs and laptops, the software application that is being updated remains inaccessible to the user during update or installation. Similarly in Kubernetes,  the application will remain inaccessible to the users during an upgrade if a proper Deployment Strategy is not used during the creation of the application. In Kubernetes, new versions are continuously developed and deployed, which means at some point you will be upgrading from an old version to the new one. However, the applications must always be accessible to the users; thus, the need for a user-friendly upgrade strategy. In this guide, we will be looking at two strategies and outline which one best suits our applications. ## Types of Deployment Strategies 1. **Recreate:** This strategy type will first destroy the existing Pods before new ones are created. During the period when the old application is down, and the new one is being brought up, the application is inaccessible to users. Looking at our [previous exercises](https://www.kubermatic.com/blog/introduction-to-kubernetes-replicasets/), we used the **recreate strategy** as it is in the YAML file. As seen under the events part of the Deployment description in part 6A, the three instances of the Pod were scaled down simultaneously before creating the new ones. Don’t forget that we updated the Deployment twice.  During the first update, the recreate strategy scaled the Pod **my-deployment-97cfc859f** down to 0, then brought up **my-deployment-79f645dc59**, and scaled it up to 3 Replicas. This was replicated during the second update by scaling the Pod **my-deployment-79f645dc59** down to 0, bringing up a new one **my-deployment-5997f87f5f**, and scaling it to 3 Replicas. This type of strategy does not allow rolling back to the previous version because it has been destroyed before an update is performed. However, don’t fret; there is another Deployment strategy that overcomes this limitation. 2. **RollingUpdate:** In contrast to the recreate strategy, the RollingUpdate strategy, which can also be referred to as **zero downtime rollouts**, is the process of updating a Kubernetes object or application sequentially by replacing each previous Pod instance with a new one. Its functionalities entail taking down the older Pod instance and bringing up a new one consecutively during an upgrade by cycling through updating the Pods according to the parameters: **maxSurge** and **maxUnavailable**.  RollingUpdate gives users unhindered access to their applications during an update and allows rolling back to the previous version in case of an error during upgrade, bugs with the new version, or if the updated version is unstable. This strategy type is the default. **maxSurge:** This is optional with the default value set to 25% or 1. It specifies the maximum number of Pods that can be created above the desired number.\ **maxUnavailable:** This is also optional with the default value set to 25% or 1. It specifies the maximum number of unavailable Pods during an update. Both properties’ values can be represented using either an absolute number(2) or percentage(25%). ### **How To Create a Deployment with the RollingUpdates Strategy** **Step 1)** Modify your configuration file, copy, and paste the below configuration with correct indentation as the values of the **strategy** property of your deployment YAML file. Save and exit the terminal: ```yaml strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 ``` The complete YAML file will look like this: ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: my-deployment spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: containers: - name: my-deployment-container image: nginx ``` **Step 2)** Check the status of the Pod. We can see all of our Pods are running: ```bash $kubectl get pods NAME READY STATUS RESTARTS AGE my-deployment-97cfc859f-8m4zk 1/1 Running 0 59s my-deployment-97cfc859f-b9j8w 1/1 Running 0 59s my-deployment-97cfc859f-hbmxn 1/1 Running 0 59s ``` **Step 3)** Check the status of the Deployment: ```bash $kubectl get deployments my-deployment NAME READY UP-TO-DATE AVAILABLE AGE my-deployment 3/3 3 3 51s ``` **Step 4)** Check the status of the latest rollout: ```bash $ kubectl get replicasets NAME DESIRED CURRENT READY AGE my-deployment-97cfc859f 3 3 3 9m21s ``` **Step 5)** Next, you will update the Deployment’s container image from nginx to nginx:1.18.0: ```bash $kubectl set image deployment/my-deployment my-deployment-container=nginx:1.18.0 --record deployment.apps/my-deployment image updated ``` Check the Pod status. Once again we have all the pods running. ```bash $ kubectl get pods NAME READY STATUS RESTARTS AGE my-deployment-79f645dc59-2ft5f 1/1 Running 0 19s my-deployment-79f645dc59-gcfgt 1/1 Running 0 34s my-deployment-79f645dc59-wtd8k 1/1 Running 0 23s ``` Check the rollout current status. We can see that we now have two deployments. The new one and the old one. ```bash $kubectl get replicaset NAME DESIRED CURRENT READY AGE my-deployment-79f645dc59 3 3 3 7m6s my-deployment-97cfc859f 0 0 0 8m23s ``` Check the Deployment description: ```bash $kubectl describe deployments my-deployment Name: my-deployment Namespace: default CreationTimestamp: Thu, 30 Jul 2020 11:39:18 +0000 Labels: <none> Annotations: deployment.kubernetes.io/revision: 2 kubernetes.io/change-cause: kubectl set image deployment/my-deployment my-deployment-container=nginx:1.18.0 --record=true Selector: app=my-app Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable StrategyType: RollingUpdate MinReadySeconds: 0 RollingUpdateStrategy: 0 max unavailable, 1 max surge Pod Template: Labels: app=my-app Containers: my-deployment-container: Image: nginx:1.18.0 Port: <none> Host Port: <none> Environment: <none> Mounts: <none> Volumes: <none> Conditions: Type Status Reason ---- ------ ------ Available True MinimumReplicasAvailable Progressing True NewReplicaSetAvailable OldReplicaSets: <none> NewReplicaSet: my-deployment-79f645dc59 (3/3 replicas created) Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ScalingReplicaSet 2m23s deployment-controller Scaled up replica set my-deployment-97cfc859f to 3 Normal ScalingReplicaSet 66s deployment-controller Scaled up replica set my-deployment-79f645dc59 to 1 Normal ScalingReplicaSet 55s deployment-controller Scaled down replica set my-deployment-97cfc859f to 2 Normal ScalingReplicaSet 55s deployment-controller Scaled up replica set my-deployment-79f645dc59 to 2 Normal ScalingReplicaSet 51s deployment-controller Scaled down replica set my-deployment-97cfc859f to 1 Normal ScalingReplicaSet 51s deployment-controller Scaled up replica set my-deployment-79f645dc59 to 3 Normal ScalingReplicaSet 46s deployment-controller Scaled down replica set my-deployment-97cfc859f to 0 ``` Looking at the events property in the Deployment description, we see that the update was done sequentially. When the Deployment was created, a ReplicaSet **my-deployment-97cfc859f** was also created and scaled up to 3 replicas. After the update, another ReplicaSet **my-deployment-79f645dc59** was created and scaled up to 1 replica, while the old ReplicaSet **my-deployment-97cfc859f** was scaled down to 2 replicas. It continued by scaling the new ReplicaSet to 2 and the old one to 1 replica respectively until the old one has been scaled down to 0 and the new one scaled up to 3 which is the desired number of the replicas. Finally, the new ReplicaSet will have 3 replicas available, while the old ReplicaSet will have 0. ### Rolling Back to a Previous Version There are times the new version might not be stable or may be filled with bugs. In this case, the application can be rolled back to the previous working or stable version. This can be performed by following these steps. **Step1)** Check the rollout history: ```bash $kubectl rollout history deployment my-deployment deployment.apps/my-deployment REVISION CHANGE-CAUSE 1 <none> 2 kubectl set image deployment/my-deployment my-deployment-container=nginx:1.18.0 --record=true ``` We updated the Deployment container image from nginx to nginx:1.18.0. However, you can revert to the previous version(nginx) from the current one(nginx:1.18.0). **Step 2)** To rollback to the previous version: ```bash $ kubectl rollout undo deployment my-deployment deployment.apps/my-deployment rolled back ``` **Step 3)** To confirm the current version, check the Deployment description: ```bash $kubectl describe my-deployment Name: my-deployment Namespace: default CreationTimestamp: Thu, 30 Jul 2020 21:27:31 +0000 Labels: <none> Annotations: deployment.kubernetes.io/revision: 3 Selector: app=my-app Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable StrategyType: RollingUpdate MinReadySeconds: 0 RollingUpdateStrategy: 0 max unavailable, 1 max surge Pod Template: Labels: app=my-app Containers: my-deployment-container: Image: nginx Port: <none> Host Port: <none> Environment: <none> Mounts: <none> Volumes: <none> Conditions: Type Status Reason ---- ------ ------ Available True MinimumReplicasAvailable Progressing True NewReplicaSetAvailable OldReplicaSets: <none> NewReplicaSet: my-deployment-97cfc859f (3/3 replicas created) Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ScalingReplicaSet 10m deployment-controller Scaled up replica set my-deployment-97cfc859f to 3 Normal ScalingReplicaSet 9m51s deployment-controller Scaled up replica set my-deployment-79f645dc59 to 1 Normal ScalingReplicaSet 9m44s deployment-controller Scaled down replica set my-deployment-97cfc859f to 2 Normal ScalingReplicaSet 9m44s deployment-controller Scaled up replica set my-deployment-79f645dc59 to 2 Normal ScalingReplicaSet 9m41s deployment-controller Scaled down replica set my-deployment-97cfc859f to 1 Normal ScalingReplicaSet 9m41s deployment-controller Scaled up replica set my-deployment-79f645dc59 to 3 Normal ScalingReplicaSet 9m38s deployment-controller Scaled down replica set my-deployment-97cfc859f to 0 Normal ScalingReplicaSet 53s deployment-controller Scaled up replica set my-deployment-97cfc859f to 1 Normal ScalingReplicaSet 50s deployment-controller Scaled down replica set my-deployment-79f645dc59 to 2 Normal ScalingReplicaSet 44s (x4 over 50s) deployment-controller (combined from similar events): Scaled down replica set my-deployment-79f645dc59 to 0 ``` The new container image from the description is **nginx** which was used to create the Deployment before the update. ### Deployment Pause and Resume You can pause a Deployment to make multiple changes and fixes and then resume it. The pause will stop the rollouts trigger while the changes are being made. It will also put all the changes and fixes made in a queue until it is resumed.We will use our previous Deployment YAML manifest file for this exercise together with a running Kubernetes cluster and kubectl command-line tool configured to talk to the cluster. You can find out more about creating a Kubernetes cluster using our open source cluster lifecycle management tool [KubeOne here](https://docs.kubermatic.com/kubeone/v1.0/). Follow the steps below to pause and resume a Deployment. **Step 1)** Create a Deployment: ```bash $ vim my-deployment.yaml ``` Copy the Deployment manifest YAML file, paste, save, and exit the terminal. ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: my-deployment spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: containers: - name: my-deployment-container image: nginx ``` Then run: ```bash $kubectl create -f my-development.yaml ## To create the Deployment deployment.apps/my-deployment created ``` **Step 2)** Check the Deployment: ```bash $kubectl get deployments my-deployment NAME READY UP-TO-DATE AVAILABLE AGE my-deployment 3/3 3 3 4m13s ``` **Step 3)** Check the description: ```bash $ kubectl describe deployments my-deployment Name: my-deployment Namespace: default CreationTimestamp: Fri, 31 Jul 2020 10:15:47 +0000 Labels: <none> Annotations: deployment.kubernetes.io/revision: 1 Selector: app=my-app Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable StrategyType: RollingUpdate MinReadySeconds: 0 RollingUpdateStrategy: 0 max unavailable, 1 max surge Pod Template: Labels: app=my-app Containers: my-deployment-container: Image: nginx Port: <none> Host Port: <none> Environment: <none> Mounts: <none> Volumes: <none> Conditions: Type Status Reason ---- ------ ------ Available True MinimumReplicasAvailable Progressing True NewReplicaSetAvailable OldReplicaSets: <none> NewReplicaSet: my-deployment-97cfc859f (3/3 replicas created) Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ScalingReplicaSet 8m6s deployment-controller Scaled up replica set my-deployment-97cfc859f to 3 ``` As seen above, there is a running Deployment with 3 Pods. **Step 4)** Pause the Deployment: ```bash $kubectl rollout pause deployment.v1.apps/my-deployment deployment.apps/my-deployment paused ``` **Step 5)** You can check if the Deployment is paused under the condition parameter in the Deployment description: ```bash $kubectl get description my-deployment Conditions: Type Status Reason ---- ------ ------ Available True MinimumReplicasAvailable Progressing Unknown DeploymentPaused OldReplicaSets: <none> NewReplicaSet: my-deployment-97cfc859f (3/3 replicas created) ``` **Step 6)** Update the Deployment by changing the container image to **nginx:1.18.0** and scale up the replica to 5. You can make as many changes as you want before resuming the Deployment. To change the container image version to **nginx:1.18.0**, run the below command: ```bash $ kubectl set image deployment/my-deployment my-deployment-container=nginx:1.18.0 --record deployment.apps/my-deployment image updated ``` To scale up the Replicas to 5 from 3, run: ```bash $kubectl scale deployment.v1.apps/my-deployment --replicas=5 deployment.apps/my-deployment scaled ``` **Step 7)** Check the rollout history: ```bash $kubectl rollout history deployment.v1.apps/my-deployment deployment.apps/my-deployment REVISION CHANGE-CAUSE 1 <none> No activities to display ``` **Step 8)** Check the status of the Deployment: ```bash $kubectl get deployments my-deployment NAME READY UP-TO-DATE AVAILABLE AGE my-deployment 5/5 0 5 31m ``` The deployment has been scaled up to 5 replicas; however, the **“UP-TO-DATE”** column shows 0; which means that the 5 replicas are still in the queue and have not been updated because of the Deployment pause state. **Step 9)** To resume the Deployment: ```bash $ kubectl rollout resume deployment.v1.apps/my-deployment deployment.apps/my-deployment resumed ``` Check the status of the Pods: ```bash $kubectl get pods NAME READY STATUS RESTARTS AGE my-deployment-79f645dc59-vkcvg 0/1 ContainerCreating 0 12s my-deployment-97cfc859f-5sqmz 1/1 Running 0 5m41s my-deployment-97cfc859f-6w44n 1/1 Running 0 5m41s my-deployment-97cfc859f-95r22 1/1 Running 0 2m2s my-deployment-97cfc859f-f5rmn 1/1 Running 0 2m2s my-deployment-97cfc859f-sqsmk 1/1 Running 0 5m41s ``` The Deployment has started creating a new Pod. Leave it for a few seconds and check the status of the Pod again. ```bash $kubectl get pods NAME READY STATUS RESTARTS AGE my-deployment-79f645dc59-44lqk 1/1 Running 0 36s my-deployment-79f645dc59-c55bk 1/1 Running 0 16s my-deployment-79f645dc59-jmbbp 1/1 Running 0 30s my-deployment-79f645dc59-kbvkr 1/1 Running 0 23s my-deployment-79f645dc59-vkcvg 1/1 Running 0 49s ``` All the Pods have now been created and are running. The old ones have been replaced with the new ones. Check the status of the Deployment ```bash $ kubectl get deployments NAME READY UP-TO-DATE AVAILABLE AGE my-deployment 5/5 5 5 6m40s ``` The Deployment is now up to date with the desired replicas Check the rollout history: ```bash $kubectl rollout history deployment.v1.apps/my-deployment deployment.apps/my-deployment REVISION CHANGE-CAUSE 1 <none> 2 kubectl set image deployment/my-deployment my-deployment-container=nginx:1.18.0 --record=true ``` To clean up: ```bash $kubectl delete my-deployment.yaml deployment.apps "my-deployment" deleted ``` Check if it has been deleted: ```bash $kubectl get deployments my-deployment No resources found in default namespace. ``` ### Using Deployment Strategies Deployment strategies are an essential feature in Kubernetes that give you more control of your application on how an update should be performed. Having seen the functionalities of both strategies, you can see that the RollingUpdate strategy usually suits applications better than the recreate strategy because we do not want the users to experience any downtime during an update.  Next, in our series, we will look at how to expose your app to the outside world using services. In that guide, you will learn Kubernetes services, types, and their usage. Furthermore we will go into details on keeping the state of app using volumes and volumeMounts. We will walk you through different types of volume and how to use them in a Pod. We’d love to hear from you!  Please [contact us](mailto:marketing@kubermatic.com) with any thoughts or questions you might have about Deployments. ### Learn More * Read more on [Deployment and ReplicaSets](https://www.kubermatic.com/blog/introduction-to-kubernetes-replicasets/). * Visit the official [Kubernetes website](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) for more resources on Deployment strategies. * Learn more on RollingUpdate strategy [here](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment) and [here](https://kubernetes.io/docs/tutorials/kubernetes-basics/update/update-intro/). --- ## How to Quickly Migrate Your Legacy Workload to Cloud Native - **URL:** https://www.kubermatic.com/resources/how-to-quickly-migrate-your-legacy-workload-to-cloud-native/ - **Date:** 2024-03-22 - **Description:** Learn how to successfully manage the transition from legacy infrastructure to cloud native. # How to Quickly Migrate Your Legacy Workload to Cloud Native ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Watch the replay to get an overview of the three main approaches to modernization - Lift & Shift, Augment, and Rewrite. Businesses are facing increasing pressures to digitize their products and services yet many lag significantly behind in their IT modernization efforts. However, when transitioning from legacy infrastructure to the cloud native era, it can be difficult to know where to begin especially with limited time and resources. This webinar walks IT leaders through the three main approaches to modernization - Lift & Shift, Augment, and Rewrite - to provide a practical guide on how to successfully manage the transition. In our presentation we cover: - Overview on main approaches to IT modernization - The challenges and benefits of each approach - Real life case studies of companies that have made the transition ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Kubernetes Security Best Practices - **URL:** https://www.kubermatic.com/blog/kubernetes-security-best-practices/ - **Date:** 2026-05-07 - **Description:** Learn more about how to approach solving security challenges of Kubernetes and container environments. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Sebastian Scheele With recent platforms like Kubernetes and containers, CVE (Common Vulnerabilities and Exposures) can be found frequently, even in the most common utilities. They can pose a range of challenges for those in charge of security. There have been cases in the past where a critical issue let an attacker take full root control of a host and all its containers. Examples like that may leave some intimidated about approaching security for Kubernetes.  By understanding the security of Kubernetes and the prominent challenges, we can address how to approach solving for them. ## What Are Kubernetes Security Issues? While adoption of Kubernetes is high, a lot of organizations are now facing troubles with security issues, according to a survey by [StackRox](https://www.stackrox.com/kubernetes-adoption-security-and-market-share-for-containers/).  The highly distributed environments of Kubernetes, often with large clusters, can expose security risks. A bad network configuration can make entire computing systems vulnerable to unauthorized access. Multiple or all of your machine can be at risk just from single nodes with an old operating system or a DoS attack.  It is difficult to monitor and trace containers due to their nature of spinning up and down frequently. Additionally, firewalls do not suit the containers domain. A key area of vulnerability in any Kubernetes environment is the code itself. The lack of ability to isolate containers effectively presents an opportunity for attacks to jeopardize sensitive data, operations, compliance and privileges.  Some prominent Kubernetes security issues and best practices outlined here will help you anticipate and avert issues when deploying your own Kubernetes instance. ## How to Address Kubernetes Security Vulnerabilities Taking proactive steps to account for security weaknesses can greatly reduce the risk of a number of negative scenarios like breaches.  With code presenting an attack service, especially in a production environment, issues can be prevented using straightforward policies like encrypting TCP using TLS handshakes, not exposing unused ports, scanning, and testing regularly. Kubernetes security tools should have these key functions: * Reduce time to guarantee code is free of compromises * Provide digital signatures to have a level of trust for code * Provide visibility and transparency in configuration issues in addition to code * Prevent incoming and outbound connection of information to unsecure services Building code from untrusted registries has its risks; untrusted code potentially opens the doors to attacks through malware or backdoors that grant access unintentionally.  Minimizing opportunities for compromise can greatly help security preparedness. Developers should get rid of unnecessary packages, libraries, and shells. Privileges should be kept as limited as possible and only the secrets necessary to a task should be mounted.  When applications are not isolated in the cluster, issues can arise. Resources and teams should be kept separate from each other using namespaces. To combat lateral motion of an attack within a cluster, policies can segment the network. Role-based access controls (RBAC) should be correctly configured to limit access.  Infrastructure elements like the API server, etcd, and controllers are all attack surfaces during runtime. There are several moving parts impacting the health of a Kubernetes cluster at any given time. In the event of an attack, compromised containers need to be quickly isolated, stopped, and replaced with healthy ones while the source of the attack is found and addressed. ## Building Your Kubernetes Security Checklist To approach your Kubernetes security with confidence, you can use this checklist to be best prepared.  1. **Begin with a minimal approach, adding only what is necessary:** To have greater control, use a minimal host OS, SELinux options, and end read-only mounts. You should scan images, OS and any outside kind, for vulnerabilities from top to bottom. No outside source can automatically be deemed trustworthy.  2. **Use namespaces and RBAC to segment the cluster and users:** Anything that isn’t necessary should not be visible. Network segmentation must be put in place pre-production because the default of Kubernetes networking allows any-to-any communications. Policies on inbound and outgoing connections should be carefully defined and routed correctly.  3. **Keep privileges to a minimum, and never run application processes as root:** Attacks that rely on installing software or modifying the file system can be stopped by way of a read-only root file system. Integrating image scanning and other security checks into the CI/CD  (Continuous Integration / Continuous Deployment) pipeline can be helpful.  4. **Secure the cluster itself:** Configuring RBAC for security entails limiting access to the API server and encrypting communications with TLS. Kubelet permissions should similarly be locked down.  5. **Ensure that only authorized images are used:** Without a process that ensures that only images adhering to the organization’s policy are allowed to run, the organization is open to risk of running vulnerable or even malicious containers. Downloading and running images from unknown sources is dangerous. It is equivalent to running software from an unknown vendor on a production server. Use private registries to store your approved images - make sure you only push approved images to these registries. This alone already narrows the playing field, reducing the number of potential images that enter your pipeline to a fraction of the hundreds of thousands of publicly available images.  Built-in controls in Kubernetes can help in managing risks, for example by configuring security context to limit pod access, so take advantage of them.  An important element to security is the practice of constantly monitoring it proactively; teams should always have a view of process activity, communications between services, and communications external to the cluster. The [CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) includes more than 100 individual checks that evaluate the security of the environment to help with compliance checks. **And now let's see if you are a Kubernetes Security expert – proof your knowledge and [start our quiz](https://www.onlinequizcreator.com/kubernetes-security-quiz/quiz-459643)!** --- ## Introducing Kubermatic Kubernetes Platform 2.15 - **URL:** https://www.kubermatic.com/blog/introducing-kubermatic-kubernetes-platform-2-15/ - **Date:** 2026-05-07 - **Description:** The latest release of Kubermatic Kubernetes Platform 2.15 comes with the new KKP installer and external cluster support. - **Categories:** Products - **Tags:** KKP - **Authors:** Kristin Wittig Today, we are thrilled to announce the release of Kubermatic Kubernetes Platform (KKP) 2.15. Significant work went into facilitating the installation process with the new KKP installer and introducing external cluster support. Read on for more details about these and other major improvements we made in this release. ### Improved Installation Experience The 2.15 release marks the first technical preview of the new KKP installer. Throughout the past releases, we learned a lot about how organizations are setting up and managing KKP, and now we can make this process much easier. While the KKP Operator, introduced in 2.14, manages KKP itself, the new installer is responsible for installing/upgrading the operator and auxiliary components, like nginx-ingress-controller, cert-manager, and others. In this preview, the installer can be used to set up a KKP master cluster. It will help with validation, proper installation procedure and guide the user in managing DNS records. Most importantly, however, the installer will take care of upgrades, reducing the manual migration steps to the minimum amount. ### Simplified User Cluster Management With New etcd-launcher With the release, we introduce the technical preview of our new etcd-launcher for facilitated user cluster management. In the past, KKP ran a static 3-node etcd ring for each user Kubernetes cluster. The new etcd-launcher provides a wrapper that runs the etcd ring and allows for more advanced operational and Day 2 capabilities. Once the etcd-launcher is enabled, users can change the size of the etcd ring up to nine nodes. Additionally, the etcd-launcher enables the etcd-ring to recover from volume or node automatically without external intervention. This makes users clusters more resilient and allows operators to provide different availability and performance configurations for their user clusters. ### More Flexibility With External Cluster Support Kubermatic Kubernetes Platform automates the deployment and Day 2 operations of Kubernetes clusters across any infrastructure from one single management UI. With the introduction of external cluster support, platform operators benefit from an even higher degree of flexibility and freedom of choice in their set-up. From now on, users will be able to connect any existing Kubernetes cluster to the system and display their details. After providing kubeconfig and the cluster name, the cluster is added to the KKP project. It retrieves the list of connected nodes, events, and metrics and displays them in the KKP UI. External clusters are displayed alongside Kubermatic clusters inside each project. This empowers operators to keep track of and control all their clusters from one single pane of glass. ### Enhanced Control With Project Restrictions To give administrators more flexibility and control in project management, we have added the possibility to restrict or limit project creation for regular users. This feature is now available from the admin settings. ### Even Less Manual Work With Dynamic Data Center Support The 2.15 release introduces the dynamic data center feature that allows users to manage their data center options for creating user clusters. As before, the data centers are part of the KKP seed, but instead of having to manually manipulate the seed objects to add or change data centers, it is now available through the API/UI. (This feature is currently only available for KKP Enterprise Edition). ### Run Kubernetes As You Like Kubermatic Kubernetes Platform 2.15 supports Kubernetes 1.19. To meet the highest security and reliability standards, we always run Kubermatic Kubernetes Platform master components with the Kubernetes version that addresses recently discovered vulnerabilities. Moreover, with the 2.15 release, we no longer support Kubernetes 1.15 and 1.16. All existing clusters will automatically be upgraded to Kubernetes 1.17. ### Learn More * Check out the entire [Changelog](https://github.com/kubermatic/kubermatic/blob/master/CHANGELOG.md) * Find Kubermatic Kubernetes Platform on [Github](https://github.com/Kubermatic/Kubermatic) --- ## Using Open Policy Agent With Kubermatic Kubernetes Platform - **URL:** https://www.kubermatic.com/blog/using-open-policy-agent-with-kubermatic/ - **Date:** 2026-05-07 - **Description:** Learn more in this tutorial that goes over all the basics of using Open Policy Agent with Kubermatic Kubernetes Platform. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Irina Lindt This article shows you how to use Open Policy Agent for policy making on a Kubernetes cluster managed by Kubermatic Kubernetes Platform (KKP). To use Open Policy Agent with Kubernetes, you have two options. You can use it as an admission controller with kube-mgmt: visit [this extensive tutorial](https://www.openpolicyagent.org/docs/latest/kubernetes-tutorial/) to see how to do that. We recommend using the more modern option with the policy controller [Gatekeeper](https://github.com/open-policy-agent/gatekeeper). Among other reasons, Gatekeeper provides an audit functionality that periodically checks all resources for violation; this is a function you have to implement yourself for the kube-mgmt option. ## What is Gatekeeper? Every time you create, update or delete a Kubernetes resource, you have the option to execute an admission controller webhook. That webhook is a HTTP callback that allows you to modify objects (mutating admission webhooks) or reject admission requests (validating admission webhooks). Gatekeeper is that type of webhook, but at the moment only a validating one, with a mutating webhook in the works. ## Installing Gatekeeper with Kubermatic Kubernetes Platform The easiest way to integrate Gatekeeper with KKP is to install a prebuilt image from the Gatekeeper server. Create a new KKP cluster, download the kubeconfig and connect to the cluster. [See our tutorials for details on that](https://docs.kubermatic.com/kubermatic/v2.17/tutorials_howtos/). Execute: ```bash $ kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml ``` You should see the following output: ```bash namespace/gatekeeper-system created customresourcedefinition.apiextensions.k8s.io/configs.config.gatekeeper.sh created customresourcedefinition.apiextensions.k8s.io/constraintpodstatuses.status.gatekeeper.sh created customresourcedefinition.apiextensions.k8s.io/constrainttemplatepodstatuses.status.gatekeeper.sh created customresourcedefinition.apiextensions.k8s.io/constrainttemplates.templates.gatekeeper.sh created serviceaccount/gatekeeper-admin created role.rbac.authorization.k8s.io/gatekeeper-manager-role created clusterrole.rbac.authorization.k8s.io/gatekeeper-manager-role created rolebinding.rbac.authorization.k8s.io/gatekeeper-manager-rolebinding created clusterrolebinding.rbac.authorization.k8s.io/gatekeeper-manager-rolebinding created secret/gatekeeper-webhook-server-cert created service/gatekeeper-webhook-service created deployment.apps/gatekeeper-audit created deployment.apps/gatekeeper-controller-manager created validatingwebhookconfiguration.admissionregistration.k8s.io/gatekeeper-validating-webhook-configuration created ``` If you prefer to install from a Helm template, execute: ```bash $ helm repo add gatekeeper https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/charts/gatekeeper $ helm install gatekeeper/gatekeeper ``` ## Using Gatekeeper You will need to define two resources: * A ConstraintTemplate that will use the Rego language to describe the policy you want to enforce * A Constraint that will tell Gatekeeper where and how to use the ConstraintTemplate. Using the examples from the Gatekeeper docs, create a ConstraintTemplate first: ```yaml apiVersion: templates.gatekeeper.sh/v1beta1 kind: ConstraintTemplate metadata: name: k8srequiredlabels spec: crd: spec: names: kind: K8sRequiredLabels listKind: K8sRequiredLabelsList plural: k8srequiredlabels singular: k8srequiredlabels validation: # Schema for the `parameters` field openAPIV3Schema: properties: labels: type: array items: string targets: - target: admission.k8s.gatekeeper.sh rego: | package k8srequiredlabels violation[{"msg": msg, "details": {"missing_labels": missing}}] { provided := {label | input.review.object.metadata.labels[label]} required := {label | label := input.parameters.labels[_]} missing := required - provided count(missing) > 0 msg := sprintf("you must provide labels: %v", [missing]) } ``` And then a Constraint: ```yaml apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sRequiredLabels metadata: name: ns-must-have-gk spec: match: kinds: - apiGroups: [""] kinds: ["Namespace"] parameters: labels: ["gatekeeper"] ``` This will install a ConstraintTemplate in your cluster which stipulates that the object must provide all labels specified by the template, as well as a Constraint which specifies that the policy must be enforced in all namespaces. The match field allows you to indicate to which resources a constraint will be applied. For example, you can select resources with certain apiGroups or kinds and specify a list of white-listed or black-listed namespaces. ## More Examples [Visit these repos](https://github.com/open-policy-agent/gatekeeper/tree/master/demo) to see more examples for ConstraintTemplates and Constraints. ## Audit Now that you have defined a policy, you can reject resources which violate it. Resources which violate this policy might have existed in the cluster before you defined the policy. In those cases, Gatekeeper brings an audit functionality which allows you to discover those resources and enforce the policy on them as well. Results are stored in the “violations” field of the Constraint object. ```yaml apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sRequiredLabels # ... status: auditTimestamp: "2019-05-11T01:46:13Z" enforced: true violations: - enforcementAction: deny kind: Namespace message: 'you must provide labels: {"gatekeeper"}' name: default - enforcementAction: deny kind: Namespace message: 'you must provide labels: {"gatekeeper"}' name: gatekeeper-system - enforcementAction: deny kind: Namespace message: 'you must provide labels: {"gatekeeper"}' name: kube-public - enforcementAction: deny kind: Namespace message: 'you must provide labels: {"gatekeeper"}' name: kube-system ``` You can adjust how often Gatekeeper audits resources during installation. To do that, you have to edit the prebuilt yaml file and add a parameter `--audit-interval` to the gatekeeper-audit resource, set to any number of seconds, or to `--audit-interval=0` to disable audit. By default, the audit runs once every 60 seconds. ## Debugging By default, Gatekeeper runs in its least verbose mode, `INFO`. You can set it to `DEBUG` by passing the argument `--log-level=DEBUG` during installation. ## Uninstalling Gatekeeper If you installed Gatekeeper from the prebuilt image, just run `kubectl delete` on that image: ```bash $ kubectl delete -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml ``` If you installed Gatekeeper using Helm: ```bash $ helm delete <release name> --purge ``` ## Additional Information * For more information on Gatekeeper, check out [Github](https://github.com/open-policy-agent/gatekeeper). * To ask Gatekeeper-specific questions, join the #kubernetes-policy channel in [the OPA Slack](https://slack.openpolicyagent.org/). * To report vulnerabilities, email them to [open-policy-agent-security](mailto:open-policy-agent-security@googlegroups.com). --- ## Kubernetes 101 Part 6.1: Keeping the State of Apps - **URL:** https://www.kubermatic.com/resources/kubernetes-101-part-6-1-keeping-the-state-of-apps/ - **Date:** 2022-12-01 - **Description:** Learn how to configure your applications and how to keep your sensitive data secret. # Keeping the State of Apps ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Watch this Epsiode of Our Webinar Series and Get Started With Keeping the State of Apps. In our Kubernetes 101 series, we cover the theoretical and technical fundamentals of Kubernetes and cloud native technologies and help you get started with containers and Kubernetes. In this episode we will bring persistence into the game. - How to configure your application? - How to keep your sensitive data secret? - Using files for the configuration of your application? - Using environment variables for the configuration of your application? - How to make Kubernetes meta info available in your application? ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Why You Need to Go Cloud Native During the Pandemic - **URL:** https://www.kubermatic.com/resources/why-you-need-to-go-cloud-native-during-the-pandemic/ - **Date:** 2024-03-22 - **Description:** Learn how containerization decreases total cost of ownership and improves innovation rates and developer productivitv. # Why You Need to Go Cloud Native During the Pandemic ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Why You Need to Go Cloud Native During the Pandemic Within the shortest time, the pandemic has been fueling digital transformation across all industries. We predict this development to split businesses into two groups: The ones who successfully adapt their transformational speed to the circumstances and those who won’t. Covid-19 has become a forcing function for cloud native - not for the sake of the buzz word but to enhance innovation, productivity, and efficiency. Within the shortest time, the pandemic has been fueling digital transformation across all industries. We predict this development to split businesses into two groups: The ones who successfully adapt their transformational speed to the circumstances and those who won’t. Covid-19 has become a forcing function for cloud native - not for the sake of the buzz word but to enhance innovation, productivity, and efficiency. In this webinar, Kubermatic CEO Sebastian Scheele explains - Why digital leaders are digital leaders - How containerization decreases total cost of ownership - How containerization improves innovation rates and developer productivity ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Project MELLODDY Meets Its Year One Objective - **URL:** https://www.kubermatic.com/blog/project-melloddy-meets-its-year-one-objective/ - **Date:** 2026-05-07 - **Description:** Project MELLODDY deploys the world’s first secure platform for multi-task federated learning in drug discovery among 10 pharmaceutical companies. - **Categories:** Company - **Tags:** Announcements - **Authors:** Kristin Wittig Today, we are excited to announce that the MELLODDY project (Machine Learning Ledger Orchestration for Drug Discovery) has met its year one objective - the deployment of the world’s first secure platform for multi-task federated learning for drug discovery. After a very intense year of collaborative effort, the platform is fully functional, audited, and tested at scale and has successfully trained a unique predictive model across ten pharma companies. What makes us particularly proud is the fact that our [Kubermatic Kubernetes Platform](https://www.kubermatic.com/products/kubermatic-kubernetes-platform/) was used to build the scalable Kubernetes infrastructure for each pharmaceutical partner. The MELLODDY Project is an Innovative Medicines Initiative-funded consortium of 10 pharmaceutical partners including [Bayer](https://www.bayer.com/), [Boehringer Ingelheim](https://www.boehringer-ingelheim.co.uk/), [GSK](https://www.gsk.com/en-gb/?gclid=EAIaIQobChMIw8b5zbjP6gIVNYBQBh2YFw4fEAAYASAAEgI-a_D_BwE&gclsrc=aw.ds), [Servier](https://servier.com/en/), and [Novartis](https://www.novartis.com/) and seven technical partners including i.a. [KU Leuven](https://www.kuleuven.be/kuleuven/), [Owkin](https://owkin.com/), [Substra](https://www.substra.ai/) Foundation and Kubermatic that has the potential to solve the challenge to cooperatively training machine learning models while protecting sensitive data to accelerate drug discovery. With today’s announcement the partners have come a good step closer to this objective. ## Project MELLODDY - A New Way of “Coopetition” Federated Learning (FL) is a Machine Learning (ML) technique that enables researchers to train artificial intelligence (AI) models on distributed data, at scale, across multiple institutions - without centralizing the data. The MELLODDY project is creating a solution that will facilitate a new form of ‘coopetition’ where competitors have a mutual interest in building predictive models that benefit from a parallel effort - while still protecting their private research, data, information, and models. MELLODDY’s successful deployment of the platform is the world’s first FL experiment in drug discovery performed at this scale and between competitive industrial partners. With this milestone achievement, 10 pharmaceutical companies, which otherwise are in competition with one another, have simultaneously trained their predictive models to learn from all the data submitted by each pharmaceutical partner. The aim of the MELLODDY consortium is to develop a cutting-edge FL platform that enables the generation and enhancement of predictive ML models, using distributed pharmaceutical data and without exposing or revealing any of the individual company’s proprietary data and models. This type of collaborative, yet still protected, data collection process has the potential to solve the challenges of data sharing within pharmaceutical research while also significantly advancing drug discovery and development opportunities. ## **Here Is How the Collaborative Model Works** Partners securely register their proprietary datasets in their own local instance of the distributed platform, which allows the private models to learn from the aggregated knowledge of all partners, without sharing private data. The development of the MELLODDY platform and the execution of the first federated run was a key milestone and a technical triumph which was achieved by the MELLODDY consortium as a first year objective of this three-year project. The design, implementation and operation of the secure platform for multi-task FL was built on the previous work and expertise of the seven technical partners. The research partners (BME, Iktos, and NVIDIA) focused on implementing ML for drug discovery, ensuring privacy, and optimizing training speed on NVIDIA GPUs while the operational partners (Owkin, Kubermatic, KU Leuven, and Substra Foundation) developed and provided the code for the platform. Owkin provided Owkin Connect, its novel privacy-preserving framework to enable multitask FL. While KU Leuven provided SparseChem, an open-source library for training ML models specific to drug discovery, we deployed our Kubermatic Kubernetes Platform to build the scalable infrastructure for each pharmaceutical partner. Finally, Substra Foundation managed the technical operations, monitored the executions of the platform, and hosted the open source code which is part of Owkin Connect. The platform passed extensive and rigorous security audits by an external company and by the IT teams of each pharmaceutical partner to ensure data privacy and protection which was an absolute prerequisite for the deployment and the project’s major challenge in the first year. Meanwhile, the pharmaceutical partners have already begun an extensive scientific and business case assessment of the results of the first cycle of modelling runs; the outcome of which, de-identified and aggregated across all partners, is considered for publication. Over the next two years, the MELLODDY project will focus on improving the performance of the common predictive model by exposing it to an increasing amount of data. ## Learn More * Visit the [MELLODDY](https://www.melloddy.eu/) website * Check out our [KubeCon Virtual Talk](https://www.youtube.com/watch?v=k5J-9d1gUd4&trk): Accelerating Drug Discovery by Cooperative Competition through Open Source * Learn more about [Kubermatic Kubernetes Platform](https://www.kubermatic.com/products/kubermatic-kubernetes-platform/) --- ## Joining the 5G Open Innovation Lab to Drive 5G Adoption - **URL:** https://www.kubermatic.com/blog/5g-open-innovation-lab-partner-release/ - **Date:** 2026-06-10 - **Description:** Kubermatic is now a member of the 5G Open Innovation Lab to drive innovation of 5G. - **Categories:** Company - **Tags:** Announcements - **Authors:** Kristin Wittig Today, we are excited to announce that we have been selected as a member of the [5G Open Innovation Lab](https://5goilab.com/), a global ecosystem of developers, start-ups, enterprises, academia, and government institutions. The 5G Open Innovation Lab is focused on helping start-ups utilize 5G to develop new capabilities, use cases, and market categories. As a member, we will work closely with the 5G OI Lab’s founding partners including [Intel](https://www.intel.com/), [T-Mobile](https://www.t-mobile.com/) and others to develop cloud native solutions to seamlessly run 5G workloads from the cloud to the core data center to the edge. Kubernetes and cloud native technologies can deliver the standardization and automation that are key to make 5G business models both operationally and financially viable. As a leading corporate contributor to the Kubernetes project, we are very much looking forward to getting involved in the Lab and shaping an exciting future. The Lab’s approach is unique in its focus on unifying an independent ecosystem by bringing together technology, financial and community partners and forward-thinking customers from industries such as media and entertainment, transportation, oil and gas, manufacturing, and retail to change the world in profound ways. For developers, the 5G OI Lab is an extraordinary opportunity to work directly with technology and business leaders to design and bring to life their vision for new 5G applications. At Kubermatic, we are emphatically committed to extending the advantages of cloud native computing to 5G technologies. We showcased our [Kubermatic Kubernetes Platform](https://www.kubermatic.com/products/kubermatic-kubernetes-platform/) as part of the first end-to-end 5G cloud native network at KubeCon San Diego in November last year, and joining the 5G OI Lab is another important milestone in pursuing a more advanced and connected future. **Learn More** * [Visit the 5G Open Innovation Lab website](https://5goilab.com/) * [Watch the E2E 5G cloud native demo on Youtube ](https://www.youtube.com/watch?v=IL4nxbmUIX8) * [Learn more about 5G on Kubernetes](/solutions/telecom/) --- ## Why the Pandemic Is a Forcing Function for Cloud Native - **URL:** https://www.kubermatic.com/blog/why-you-need-to-go-cloud-native-during-the-pandemic/ - **Date:** 2026-05-07 - **Description:** Covid-19 is a forcing function for cloud native; not for the sake of the buzzword, but to enhance innovation, productivity, and efficiency. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Sebastian Scheele It’s been breaking news over the past few weeks: For the second quarter of 2020, Zoom reported an incredible 355% revenue growth compared to the previous year. If there was any more proof needed that the pandemic has been fueling digital transformation faster than ever, this it checked off. I predict this development to split businesses into two groups: 1. Those who successfully adapt their transformational speed to the new circumstances 2. and those who won't. Ultimately, that will reinforce the gap between digital leaders and digital laggards for good. Covid-19 has become a forcing function for cloud native to truly enhance innovation, user experience, and developer productivity while steadily decreasing infrastructure and operational cost. Before we dive deeper into that, let’s first take one step back: Traditionally, IT departments were used to build software based on their projections of future customer needs and tied to the pace their operations could deliver. This often resulted in unstable (or even unwanted) products and ultimately high OPEX and R&D costs, sluggish innovation, and a poor talent pool. Or as we like to call it, a cycle of inefficiency. ![Cycle of Inefficiency](/static/cycle-of-inefficiency.png "Cycle of Inefficiency") Sure, we have seen many businesses adopt cloud native and DevOps approaches over the past few years already. However, the pandemic has made it even more critical to escape this vicious cycle. With the explosion in the number of remote devices and remote customers, having scalable systems and optimal user experience (internal and external) have become vital for continued businesses success. This is exactly what cloud native technologies bring to the table: * Developing applications that are flexible to quickly respond to changing circumstances and new requirements * Experimenting with new ideas and features that incrementally drive innovation (remember how quickly Lieferando released a new Pickup feature after the restaurants closed down?) * Building loosely coupled microservices that are much more resilient and minimize downtime * Moving away from always-on infrastructure to infrastructure that scales on demand and is billed and paid per use In summary: entering a cycle of efficiency that is able to support your business goals and ensure future competitiveness. ![Cycle of Efficiency](/static/cycle-of-efficiency.png "Cycle of Efficiency") Admittedly, in the past, cloud native has been somewhat limited to the public cloud and containerized applications, preventing many businesses from embarking on their cloud native journey. Why and how would you want to get rid of your Virtual Machines, your legacy applications or your data centers? Luckily (and in time for a changed world) these reserves do not hold true anymore: The community has developed effective tooling that brings the benefits of cloud native to any possible workload and infrastructure. The [KubeVirt](https://kubevirt.io/) project, for example, addresses the needs of teams that want to adopt Kubernetes but have VM-based workloads that cannot be easily containerized. Platforms like our [Kubermatic Kubernetes Platform](https://www.kubermatic.com/products/kubermatic-kubernetes-platform/) automate the management of thousands of Kubernetes clusters across any infrastructure: from your data center, to any public cloud, and even up to edge and IoT environments. The cloud native ecosystem is ready for enterprise adoption. Now, businesses need to get ready too, if they want to emerge from this crisis as digital leaders and not as digital laggards. ## Learn More * Join our Webinar: Why You Really Should Go Cloud Native During the Pandemic on September 16 at 6 PM CEST ([Watch here](https://www.youtube.com/watch?v=L8ob667kBsk&t=1s)) * Check out our recording on how to easily set up your own cloud native platform across any infrastructure with open source Kubermatic Kubernetes Platform ([View here](https://www.youtube.com/watch?v=1LQc4HAjBKE)) --- ## Introduction to Open Policy Agent - **URL:** https://www.kubermatic.com/blog/introduction-to-open-policy-agent/ - **Date:** 2026-05-07 - **Description:** A broad introduction to Open Policy Agent, its uses and building blocks - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Irina Lindt ### What Is Open Policy Agent? Open Policy Agent is a project which allows you to implement fine-grained access control. It is written in Go and is part of the Cloud Native Computing Foundation as an incubating project. Its [source code](https://github.com/open-policy-agent/opa) is available publicly under the Apache License 2.0. ### Why Use OPA? Policy-making has been implemented with various frameworks in the past (have a look at the [AWS policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) for an example). OPA attempts to unify these different approaches and allows you to use the same tool for policy-making across your different services. ### Who Uses OPA? OPA can now be used with Kubermatic Kubernetes Platform. Additionally, companies and projects like [Docker](https://www.docker.com), [Istio](https://istio.io), [Kafka](https://kafka.apache.org) and [Terraform](https://www.terraform.io) use OPA to implement their policy decision making. There are [tutorials on the OPA website](https://www.openpolicyagent.org/docs/latest/docker-authorization/) showing you how to implement decision making with these products. We will show how to use Kubermatic Kubernetes Platform with OPA in our next tutorial. ### What Are the Basic Components of OPA? OPA lets you define policy as source code. The language used within OPA is [Rego](https://www.openpolicyagent.org/docs/latest/policy-language/), OPA’s native query language. Decision making with OPA consists of three components: * Data: The first component is all the information about your domain that OPA will use to make decisions. For example, it might be a list of users or a list of endpoints. * Query Input: The second element is the question your application sends to OPA. It must be formatted in JSON. The question might effectively be, for example, “is the user X authorized to access ressource Y?” * Policy: The final component is the policy which OPA uses to make a decision and return the result to you. It might be a simple “yes” or “no.” Note that you still have to implement your application’s response to the policy yourself; i.e. if the user is not authorized, it is your responsibility to implement the resulting notification. ### Which APIs Are Part of OPA? You can use the following APIs within OPA: * Bundle service API: This is what you use to send policy data to OPA. OPA constantly checks it to ensure the current policy version is up-to-date. * Status service API: This is what you use to determine the current status of the service. * Decision log service API: This is the logging component which records every decision made by OPA. It is particularly useful for troubleshooting. ### What We Have Learned So Far * OPA is a project to unify policy decision making across your services * It defines policy as code * It has its own language, Rego * We have seen an overview of the building blocks of OPA and its main APIs ### See Our Next Tutorial for Information on These Topics * Using OPA with a Kubermatic Kubernetes Platform (KKP) cluster * The project Gatekeeper and how it simplifies working with OPA * How to audit pre-existing resources * Where to find additional resources --- ## Getting Started With KubeCarrier - **URL:** https://www.kubermatic.com/blog/getting-started-with-kubecarrier/ - **Date:** 2026-05-07 - **Description:** Learn how to install KubeCarrier in Kubernetes clusters, connect your first service cluster, and manage your first service via KubeCarrier service hub. - **Categories:** Community - **Tags:** Open Source Projects - **Authors:** Jiacheng Xu ## **Why KubeCarrier?** One of Kubernetes greatest – and most difficult to keep – promises is the ability to eliminate much of the operational burden of managing applications and services on multi-cloud infrastructure. Kubernetes Operators deliver on this promise by automating the management of applications and services lifecycle. However, provisioning, reconfiguring, and tearing down applications and services across multiple clusters is still hard and time-intensive. With the power of Kubernetes Operators, it is easy to deploy and manage your applications with Kubernetes. However, there is no standard way and central management platform to provide your services and applications to people and make your applications accessible via a service catalog. We believe that multi-cloud is the future, and managing services across multi-cloud infrastructure should be simple. IT people should focus on their core business or technical logic in the cloud-native fashion while leaving cross-cluster service management into safe and experienced hands. We can not find an existing project which meets our requirements. That’s why we built [KubeCarrier](https://github.com/kubermatic/kubecarrier), a generic solution to manage services on multi-cloud. ## What Is KubeCarrier? [KubeCarrier](https://github.com/kubermatic/kubecarrier) is an open source project that addresses the complexities of automated full lifecycle management by harnessing the Kubernetes API and Operators into a central framework, allowing platform operators to deliver cloud native service management from one multi-cloud, multi-cluster hub. KubeCarrier provides you: * A central service hub to manage services across multi-cloud infrastructure * Multi-tenancy and user management with access right controls, permissions, and policies to define quotas Here is an example of how KubeCarrier delivers these features: ![How KubeCarrier provides a central service hub to manage services, multi tenancy and user management](/static/how-kubecarrier-provides-a-central-service-hub-to-manage-services-multi-tenancy-and-user-management.png) You have a redis operator running in your service cluster to provide redis database services, and there is a KubeCarrier installation running in a central management cluster. The only thing you need to do is to register your service cluster to KubeCarrier, and KubeCarrier will automatically discover the available redis services in the service cluster, and make them available in management and distribution in the central service hub. Via the KubeCarrier service hub, your redis service will be available to users in KubeCarrier multi-tenancy environment, and you just lay back and leave service management into safe and experienced hands! Overall: * If you desire to share and provider your services to other people and organisations, but you don’t know where to make them accessible, * If you want to use some reliable services instead of building everything yourself from scratch, KubeCarrier service hub is definitely the right place to try! ## Getting Started In this guide, we will show you how to install KubeCarrier in Kubernetes, how to connect your first service cluster, and how to manage your first service via the KubeCarrier service hub. ### Requirements To install KubeCarrier, you need a Kubernetes Cluster with the [cert-manager](https://cert-manager.io/docs/) installed. * Kubernetes: v1.16, v1.17, v1.18 * cert-manager: v0.14.0 ### Kubernetes Clusters For the purposes of this tutorial, we are using [kind - Kubernetes IN Docker](https://github.com/kubernetes-sigs/kind) as our Kubernetes cluster. In a production setup you might use Kubermatic Kubernetes Platform, or any other valid Kubernetes cluster provider. ```bash # Management Cluster $ kind create cluster --name=kubecarrier ``` ### Deploy cert-manager ```bash # deploy cert-manager $ kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v0.14.0/cert-manager.yaml # wait for it to be ready (optional) $ kubectl wait --for=condition=available deployment/cert-manager -n cert-manager --timeout=120s $ kubectl wait --for=condition=available deployment/cert-manager-cainjector -n cert-manager --timeout=120s $ kubectl wait --for=condition=available deployment/cert-manager-webhook -n cert-manager --timeout=120s ``` ## Installation KubeCarrier is distributed via a public container registry: [quay.io/kubecarrier](https://quay.io/kubecarrier). While the KubeCarrier installation is managed by the KubeCarrier operator, installing and upgrading the operator is done via our kubectl plugin. This Command-line interface (CLI) tool will gain more utility functions as the project matures. ### Install the Kubectl Plugin To install the kubectl plugin, visit the KubeCarrier [release page](https://github.com/kubermatic/kubecarrier/releases), download the archive and put the contained kubecarrier binary into your $PATH as kubectl-kubecarrier. You can also use it as a standalone binary without renaming it to kubectl plugin if preferable. Make sure the binary is executable. Check the KubeCarrier installer version: ```bash $ kubectl kubecarrier version --full ``` Ensure you are running the latest release (the `v0.3.0`) with our up-to-date fixes, features, and security enhancement. ### Install KubeCarrier ```bash # make sure you are connected to the cluster, # that you want to install KubeCarrier on $ kubectl config current-context kind-kubecarrier # install KubeCarrier $ kubectl kubecarrier setup 0.03s ✔ Create "kubecarrier-system" Namespace 0.19s ✔ Deploy KubeCarrier Operator 6.29s ✔ Deploy KubeCarrier ``` The `kubectl kubecarrier setup` command is idempotent, so if you encounter any error in your setup, it's safe to re-run it multiple times. ### API Access KubeCarrier also deploys its own API Server to allow external access and integrations to connect with KubeCarrier. It is designed as a slim interface layer and all the heavy lifting (validation, authorization, etc.) is still done by Kubernetes Controllers, Kubernetes Admission Webhooks, and other Kubernetes mechanisms. The KubeCarrier API Server supports multiple authentication methods. By default, kubectl kubecarrier setup starts the KubeCarrier API Server with ServiceAccount and Anonymous authentication methods enabled. KubeCarrier will also generate a self-signed certificate for localhost and 127.0.0.1 as a minimal TLS setup. For more information, please refer to our [official documentation](https://docs.kubermatic.com/), and see how to customize the KubeCarrier API server with different authentication methods and your own TLS setup. ## Accounts KubeCarrier manages everything in accounts and each account is separated by its own Namespace. Subjects within the Account get RBAC Roles set up and assigned, so they can interact with the system. To start with KubeCarrier, we will create two accounts. The first account team-a, will provide services, while team-b will be able to consume services. Each Account has a list of subjects, similar to [RoleBinding](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#rolebinding-v1-rbac-authorization-k8s-io) objects. These subjects will be set up with admin rights for their namespace. Accounts with the: * Provider role can register ServiceCluster, manage Catalogs, and organize their services * Tenant role can create services that were made available to them via Catalogs from a Provider Accounts may be a Provider and a Tenant at the same time. ```yaml apiVersion: catalog.kubecarrier.io/v1alpha1 kind: Account metadata: name: team-a spec: metadata: displayName: The A Team description: In 1972, a crack commando unit was sent to... roles: - Provider subjects: - kind: User name: hannibal apiGroup: rbac.authorization.k8s.io - kind: User name: team-a-member apiGroup: rbac.authorization.k8s.io --- apiVersion: catalog.kubecarrier.io/v1alpha1 kind: Account metadata: name: team-b spec: roles: - Tenant subjects: - kind: User name: team-b-member apiGroup: rbac.authorization.k8s.i ``` To create these objects, just run: ```bash $ kubectl apply -f https://raw.githubusercontent.com/kubermatic/kubecarrier/v0.3.0/docs/manifests/accounts.yaml ``` After creating those accounts, you can check their status and namespace: ```bash $ kubectl get account NAME ACCOUNT NAMESPACE DISPLAY NAME STATUS AGE team-a team-a The A Team Ready 7s team-b team-b Ready 7s ``` Note: We will look more at the differences between the Provider and Tenant roles for accounts in our next blog about *Service Hub With KubeCarrier*. ## Service Clusters The next step is to register Kubernetes clusters into KubeCarrier. To begin, you need another Kubeconfig. If you don’t have another Kubernetes cluster, go back to Requirements and create another cluster with Kind. In this example, we use the name eu-west-1 for this new cluster. When you create another cluster with Kind, you have to work with the internal Kubeconfig of the cluster, using the following command: ```bash $ kind get kubeconfig --internal --name eu-west-1 > /tmp/eu-west-1-kubeconfig ``` This will replace the default `localhost:xxxx` address with the container’s IP address, allowing KubeCarrier to talk with the other Kind cluster. When creating a new cluster with `kind` your active context will be switched to the newly created cluster. Check `kubectl config current-context` and use `kubectl config use-context` to switch back to the right cluster. To begin, you have to upload your Kubeconfig as a `Secret` into the Account Namespace. ```bash $ kubectl create secret generic eu-west-1-kubeconfig \ -n team-a \ --from-file=kubeconfig=/tmp/eu-west-1-kubeconfig ``` Now that the credentials and connection information are in place, we can register the cluster into KubeCarrier. ```yaml apiVersion: kubecarrier.io/v1alpha1 kind: ServiceCluster metadata: name: eu-west-1 spec: metadata: displayName: EU West 1 kubeconfigSecret: name: eu-west-1-kubeconfig ``` Create the object with: ```bash $ kubectl apply -n team-a \ -f https://raw.githubusercontent.com/kubermatic/kubecarrier/v0.3.0/docs/manifests/servicecluster.yaml ``` ```bash $ kubectl get servicecluster -n team-a NAME STATUS DISPLAY NAME KUBERNETES VERSION AGE eu-west-1 Ready EU West 1 v1.18.0 8s ``` KubeCarrier will connect to the cluster, do basic health checking, and report the Kubernetes Version. Now, you have a service cluster that is connected to KubeCarrier! ## Catalogs ### CatalogEntrySet In this chapter, we show how to manage your services across multiple service clusters via the KubeCarrier service hub. To begin with, you need to have CustomResourceDefinitions (CRD) or operator installations in the service cluster. In this tutorial, we will use a CRD as an example. Let’s register the example CRD in the service cluster that we created in the previous step. Make sure you are connected to the service cluster: ```bash $ kubectl config use-context kind-eu-west-1 ``` Then register the CRD to the service cluster: ```bash kubectl apply \ -f https://raw.githubusercontent.com/kubermatic/kubecarrier/v0.3.0/docs/manifests/couchdb.crd.yaml ``` Now, tell KubeCarrier to work with this CRD. For doing that, we create a `CatalogEntrySet` object in this example. This object describes which CRD should be fetched from which service cluster to the KubeCarrier central management cluster, and which fields will be available to users. Here is an example: ```yaml apiVersion: catalog.kubecarrier.io/v1alpha1 kind: CatalogEntrySet metadata: name: couchdbs.eu-west-1 spec: metadata: displayName: CouchDB description: The CouchDB database discover: crd: name: couchdbs.couchdb.io serviceClusterSelector: {} derive: expose: - versions: - v1alpha1 fields: - jsonPath: .spec.username - jsonPath: .spec.password - jsonPath: .status.phase - jsonPath: .status.fauxtonAddress - jsonPath: .status.address - jsonPath: .status.observedGeneration ``` Note: Don’t worry if you are not familiar with KubeCarrier objects! In our next blog, we will talk about Service Management with KubeCarrier in depth, and you can also find [KubeCarrier API reference](https://docs.kubermatic.com/) in our documentation website. Then we switch to our central management cluster: ```bash $ kubectl config use-context kind-kubecarrier ``` Create the `CatalogEntrySet` object above: ```bash $ kubectl apply -n team-a \ -f https://raw.githubusercontent.com/kubermatic/kubecarrier/v0.3.0/docs/manifests/catalogentryset.yaml ``` Once the `CatalogEntrySet` object is ready, you will notice two new CRDs appearing in the management cluster: ```bash $ kubectl get crd -l kubecarrier.io/origin-namespace=team-a ``` ``` NAME CREATED AT couchdbs.eu-west-1.team-a 2020-07-31T09:36:04Z couchdbs.internal.eu-west-1.team-a 2020-07-31T09:35:50Z ``` The `couchdbs.internal.eu-west-1.team-a` CRD is just a copy of the CRD present in the `ServiceCluster`, while `couchdbs.eu-west-1.team-a` is a “slimmed-down” version, only containing fields specified in the `CatalogEntrySet`. Both CRDs are “namespaced” by their API group. The `CatalogEntrySet` object we created in the previous step is managing `CatalogEntry` objects for service clusters that match the `serviceClusterSelector: ```bash $ kubectl get catalogentry -n team-a ``` ``` NAME STATUS BASE CRD TENANT CRD AGE couchdbs.eu-west-1 Ready couchdbs.internal.eu-west-1.team-a couchdbs.eu-west-1.team-a 26s ``` We can now reference this `CatalogEntry` in a `Catalog` and offer it to `Tenant`! For Every Account with the Tenant role, a Tenant object is created in each Provider namespace. In our example, `Provider` team-a can check `Tenant` in the system by: ```bash $ kubectl get tenant -n team-a ``` ``` NAME AGE team-b 5m35s ``` Then team-a can offer the CouchDB `CatalogEntry` to `Tenant` team-b by creating the following `Catalog` object: ```yaml apiVersion: catalog.kubecarrier.io/v1alpha1 kind: Catalog metadata: name: default spec: # selects all the Tenants tenantSelector: {} # selects all the CatalogEntries catalogEntrySelector: {} ``` ```bash $ kubectl apply -n team-a \ -f https://raw.githubusercontent.com/kubermatic/kubecarrier/v0.3.0/docs/manifests/catalog.yaml ``` When the Catalog is ready, selected tenants can discover objects available to them and [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) is set up for users to work with the CRD in their namespace. Here we also use kubectl user impersonation (`--as`), to showcase RBAC: ```bash # Offering objects contain information about CRDs that are shared to a Tenant. # They contain all the information to validate and create new instances. $ kubectl get offering -n team-b --as=team-b-member ``` ``` NAME DISPLAY NAME PROVIDER AGE couchdbs.eu-west-1.team-a CouchDB team-a 3m15s ``` ```bash # Region exposes information about the underlying Clusters. $ kubectl get region -n team-b --as=team-b-member ``` ``` NAME PROVIDER DISPLAY NAME AGE eu-west-1.team-a team-a EU West 1 5m14s ``` ```bash # Provider exposes information about the Provider of an Offering. $ kubectl get provider -n team-b --as=team-b-member ``` ``` NAME DISPLAY NAME AGE team-a The A Team 6m11s ``` ## First Service Instance! Now, everything is set up! Time to create the first service instance. As team-b, we can create our first CouchDB object: ```yaml apiVersion: eu-west-1.team-a/v1alpha1 kind: CouchDB metadata: name: db1 spec: username: hans password: hans2000 ``` ```bash kubectl apply -n team-b --as=team-b-member \ -f https://raw.githubusercontent.com/kubermatic/kubecarrier/v0.3.0/docs/manifests/couchdb.eu-west-1.yaml ``` Team-a is offering the `CouchDB` service from service cluster `eu-west-1` and Team-b created an instance of the `CouchDB` service! ## What's Next? In this guide, you have seen how simple it is to install KubeCarrier in a Kubernetes cluster, connect a service cluster, and manage a service via KubeCarrier service hub. In our next blog, we will show you more advanced features in depth about service management via KubeCarrier. **Learn More:** * KubeCarrier Documentation: [https://docs.kubermatic.com/kubecarrier/v0.3/](https://docs.kubermatic.com/kubecarrier/v0.2/) * KubeCarrier Github Repository: <https://github.com/kubermatic/kubecarrier> --- ## Accelerating Drug Discovery: Competitive Cooperation OS - **URL:** https://www.kubermatic.com/resources/accelerating-drug-discovery-by-competitive-cooperation-through-os/ - **Date:** 2024-03-21 - **Description:** Learn more about the machine learning based drug discovery consortium “MELLODDY”. # KubeCon Europe Virtual 2020: Accelerating Drug Discovery by Competitive Cooperation Through Open Source ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Watch the Video to Find Out how Kubermatic Kubernetes Platform Contributes to the Project. In this talk Bill Mulligan from Kubermatic and Camille Marini from Owkin speak about the machine learning based drug discovery consortium “MELLODDY” and how it boosts drug discovery model development while addressing both security and privacy preservation concerns. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Unveiling KubeOne 1.0: Simplified Kubernetes Operations - **URL:** https://www.kubermatic.com/blog/unveiling-kubeone-1-simplified-kubernetes-operations-for-everyone/ - **Date:** 2026-05-07 - **Description:** Our open source cluster lifecycle management tool for single Kubernetes clusters in the cloud, the datacenter or on the edge is now production-ready. - **Categories:** Products, Community - **Tags:** KubeOne, Open Source Projects - **Authors:** Kristin Wittig Just in time for KubeCon + CloudNativeCon Europe Virtual, we are excited to announce general availability of KubeOne 1.0. KubeOne is an [open source cluster lifecycle management tool](https://github.com/kubermatic/kubeone) for single Kubernetes clusters. It automates the deployment and Day 2 operations of Highly Available clusters to make your life easier everywhere: KubeOne works in the cloud, the datacenter, as well as in edge and IoT environments. We first released KubeOne prior to KubeCon Barcelona in May 2019. 15 months, 760 commits, and 600 Github stars later, we are proud to have achieved this milestone. This major release is another important step in fulfilling our mission of achieving full operation automation – regardless of the underlying infrastructure. Major highlights of the release include: **Complete Cluster Reconciliation Using a Single Command** KubeOne 1.0 comes with a new `apply` command which takes care of the complete cluster reconciliation, including provisioning, upgrading, and repairing clusters. The `apply` command is capable of creating new worker nodes, reconciling addons, and can be used in complex scenarios such as disaster recovery. **KubeOneCluster API Promoted to Beta** The KubeOneCluster API has been promoted to v1beta1, bringing more stability, maturity, and many other improvements. The new API makes it easier to manage the cluster in a clear and concise way, and use all the new features. Users can easily migrate all existing manifests to the new API by using the `kubeone config migrate` command. **Static Worker Nodes Support for Bare-metal, IoT, and Edge Environments** KubeOne 1.0 introduces support for provisioning Kubernetes clusters with static worker nodes. This simplifies the management of Kubernetes clusters on bare-metal, IoT, edge, and other environments not supported by machine-controller. The new Static Worker Nodes Feature empowers users to create instances using their preferred approach, define them in the cluster configuration, and let KubeOne provision and join them to the cluster. **Deploy the CNI Plugin of Your Choice** KubeOne 1.0 adds the option to deploy any CNI plugin. In combination with a powerful addon mechanism, users can ensure that the CNI plugin of their choice is deployed right on the provisioning time. **Extended OS Support With Flatcar, CentOS 8, and RHEL** The 1.0 release introduces support of [Flatcar Container Linux](https://www.flatcar-linux.org/) as a replacement of CoreOS. The CentOS support has been extended with the support of CentOS 8. Besides Flatcar and CentOS 8, the OS support has been extended with Red Hat Enterprise Linux (RHEL). Learn More * Find [KubeOne on Github](https://github.com/kubermatic/kubeone) * See the KubeOne [Documentation](https://docs.kubermatic.com/kubeone/v1.0/) * Check out the entire [Changelog](https://github.com/kubermatic/kubeone/blob/master/CHANGELOG.md) * KubeOne 1.0 [Release Note](https://github.com/kubermatic/kubeone/releases) --- ## Operate Services the Cloud Native Way With KubeCarrier - **URL:** https://www.kubermatic.com/resources/introducing-kubecarrier-operating-services-the-cloud-native-way/ - **Date:** 2026-03-17 - **Description:** Learn why we build KubeCarrier and how you can get started with the project. # Operate Services the Cloud Native Way With KubeCarrier ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Watch Our Webinar to Make an Important Step on the Road Towards Full Kubernetes Operation Automation. As cloud native adoption accelerates, operation teams are confronted with the complexities of service management across multiple clusters, clouds, and regions. They struggle with enterprise-grade compliance and the operational burden involved. KubeCarrier addresses these complexities by harnessing the Kubernetes API and Operators into a central framework allowing operators to deliver cloud native service management from one multi-cloud, multi-cluster hub. With KubeCarrier, internal or external customers can immediately deploy the cloud native software and services they need, including databases, data stores, monitoring, service meshes, and other Kubernetes tooling. In this session, you will learn why we build KubeCarrier and how you can get started with the project. This session covers: - Project Background - Architecture - Getting Started ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Kubermatic News: KubeCon Europe Virtual - **URL:** https://www.kubermatic.com/blog/kubermatic-kubercon-europe-virtual-news/ - **Date:** 2026-05-07 - **Description:** Get all you need to know about KubeCon Europe Virtuel here - **Categories:** Community - **Tags:** Open Source Projects - **Authors:** Kristin Wittig The countdown is on – only a few days left until **KubeCon Europe Virtual 2020** starts! We are extremely excited to get started for this special online edition of the conference and we hope you are too. KubeCon usually means three busy days full of talks, meetings and side events. To be well prepared and to not miss any cool opportunities, check out what we have planned during and in the days leading up to the online event. **Here's what else Kubermatic is doing at KubeCon:** * Join our Day 0 workshop: Getting Started With Kubermatic Kubernetes Platform – Installation and Usage * Sign up for our webinar: Introducing KubeCarrier – Operating Services the Cloud Native Way * Kubermatic Kubernetes Platform is now open source! Learn more about this exciting milestone and meet us at our booth in the Startup Hall A * Check out Bill's talk on accelerating drug discovery by competitive cooperation through open source * If you want to chat with us outside the event platform, please join our Kubermatic channel within the KubeCon Slack workspace ![Kubermatic Platform Installation and Usage](/static/online-workshop_getting-started-with-kubermatic-kubernetes-platform_kubecon-virtual-edited.png) **Join Our Day 0 Workshop** In this workshop, you will learn how to install Kubermatic Kubernetes Platform on an existing Kubernetes cluster. Topics covered in this session: * Architecture overview * How to setup Kubermatic master and seeds including the required infrastructure * How to deploy user clusters * Introduction to advanced use cases and multi location / cloud setups:+1 * Demo: Setting up Kubermatic from scratch on GCE/AWS? **Sign Up!** ![Introducing KubeCarrier](/static/edited-image-4-1.jpg) **Join Our Webinar: Introducing KubeCarrier** In this webinar, you will learn how to operate services across multiple clusters, clouds, and regions in a truely cloud native way leveraging Kubernetes Operators with project KubeCarrier. This session covers: * Project Background * Architecture * Getting Started **[Join Our Webinar!](https://www.youtube.com/watch?v=v_EG7f9UU0Y&t=349s)** ![Virtual KubeCon Europe booths](/static/bronze-hall-a-e1593036352857.jpg) **Meet Us At Our Booth In The Startup Hall A** Exciting days are behind us – with the announcement of open sourcing Kubermatic Kubernetes Platform on June 17, 2020, we made the core software code publicly available under the Apache 2.0 License. In line with our strong commitment to make Kubernetes as boring as possible, we want to empower IT teams everywhere to automate the management of hundreds or thousands of Kubernetes clusters regardless of the underlying infrastructure. Beyond that, we have big plans for more interesting and cool open source projects. Visit us at our virtual booth in the Startup Hall A and find out more! If you want to make sure that we’ve got time for a chat or a demo, schedule a 1:1 with us now. **[Book A Meeting!](https://meetings.hubspot.com/julian44/15-minute-meeting?utm_campaign=KubeCon%20Europe%20Virtual%202020&utm_source=hs_email&utm_medium=email&_hsenc=p2ANqtz-8obmWBgj_AZbOGON01sgGwTvlaTk7-x7WAeOGsVKpD-CV2JwoIH3g-ilrSigYBufIBfCX4)** ![Talk at KubeCon Virtual: Accelerating Drug Discovery](/static/talk-at-kubecon-virtual_accelerating-drug-discovery-by-competitive-cooperation-through-open-source-jul-23-2020-07-28-44-76-pm-1.jpg) **Accelerating Drug Discovery by Competitive Cooperation Through Open Source** Camille from Owkin and Bill from Loodse are going to talk about the machine learning based drug discovery consortium "MELLODDY" and how it boosts drug discovery model development while addressing both security and privacy preservation concerns. Kubernetes provides the consistent computing infrastructure across companies, ensuring that data owners maintain control while running the common ML software and sharing the resulting models. The talk is on Wednesday August 19 at 1:45 PM CEST. **[Find Out More](https://kccnceu20.sched.com/event/ZetX/accelerating-drug-discovery-by-competitive-cooperation-through-open-source-bill-mulligan-loodse-camille-marini-owkin?utm_campaign=KubeCon%20Europe%20Virtual%202020&utm_source=hs_email&utm_medium=email&_hsenc=p2ANqtz-8obmWBgj_AZbOGON01sgGwTvlaTk7-x7WAeOGsVKpD-CV2JwoIH3g-ilrSigYBufIBfCX4)** **Find Us On KubeCon Slack** If you want to chat with us outside the event platform, please join our Kubermatic channel **\#6-kubecon-kubermatic** within the KubeCon Slack workspace. We are looking forward to meeting you. **[Join Slack](https://slack.cncf.io/?utm_campaign=KubeCon%20Europe%20Virtual%202020&utm_source=hs_email&utm_medium=email&_hsenc=p2ANqtz-8obmWBgj_AZbOGON01sgGwTvlaTk7-x7WAeOGsVKpD-CV2JwoIH3g-ilrSigYBufIBfCX4)** --- ## Kubernetes 101 Part 5: Exposing Apps - **URL:** https://www.kubermatic.com/resources/kubernetes-101-part-5-exposing-apps/ - **Date:** 2022-12-01 - **Description:** Learn how to expose your applications to other services or applications both within and outside of Kubernetes. # Exposing Apps ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Watch the Fifth Part of Our Webinar Series and Get Started With Exposing Apps. In our Kubernetes 101 series, we cover the theoretical and technical fundamentals of Kubernetes and cloud native technologies and help you get started with containers and Kubernetes. In this episode, you will learn how to expose your applications to other services or applications both within and outside of Kubernetes. Moreover, we will show the different types of services and their pros and cons. Topics covered in this session: - Why do we need Services? - What is an Endpoint in Kubernetes? - What is a Kubernetes Service and how does it expose a set of Pods? - What are the different types of Services and when to use them? ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Kubermatic News For July 2020 - **URL:** https://www.kubermatic.com/blog/kubermatic-news-for-july/ - **Date:** 2026-05-07 - **Description:** All the important news about and around Kubermatic and the Cloud Native Community for July - **Categories:** Company - **Tags:** Announcements - **Authors:** Kristin Wittig With the release of **Kubermatic Kubernetes Platform 2.14** we also open sourced it under Apache 2.0 licence. It was the right step at the right time and we hope to give something back to the community with this move. **Other Highlights This Month:** * Learn how to get rid of your Kube Chaos with Kubernetes multi-cluster management * Kubermatic @KubeCon Europe Virtual 2020 * Learn how to use open source Kubermatic KubeOne to deploy a 5G Core Poc * Listen to the Kubernetes Podcast 'Talking Kubermatic with Sebastian Scheele' from Google * Find the right Kubermatic Webinar for you – either live or recorded ![Low angle fire works](/static/low-angle-photo-of-fireworks-949592_hu3d03a01dcc18bc5be0e67db3d8d209a6_420015_800x420_fill_q75_box_smart1-2-.jpg) **Introducing Kubermatic Kubernetes Platform 2.14** Kubermatic Kubernetes Platform 2.14 is the first open source release of our core cloud native platform. Significant work went into making Kubermatic Kubernetes Platform available as a community project under the Apache 2.0 Licence. This step empowers IT teams everywhere to automate the management of hundreds or thousands of Kubernetes clusters regardless of the underlying infrastructure. Noteworthy Highlights: * Run containers and VMs side by side with Kubermatic Virtualization * Extend policies with open policy agent (preview) * Extended OS support with flatcar * More freedom of choice with native support of Alibaba Cloud Check out all details of the Kubermatic Kubernetes Platform 2.14 release in our [Changelog.](https://github.com/kubermatic/kubermatic/blob/master/CHANGELOG.md) **[Read More ](https://www.kubermatic.com/blog/introducing-kubermatic-kubernetes-platform-2-14/?utm_source=hs_email&utm_medium=email&_hsenc=p2ANqtz-90wCbuHLUJVeQA4dR81pJlXQS82ONBLkGrOqDPuNY28bYkwNqdu9T9HsxBip5iWypDFoAp)** ![ KuberCon Virtual log ](/static/screenshot-2020-08-10-at-2.25.05-pm.png) **Find Us At KubeCon Europe Virtual 2020** KubeCon Europe 2020, as a completely virtual event, will be different. Nevertheless the focus on Kubernetes and Cloud Native technologies will remain the same. We are excited to be part of this new experience and looking forward to getting into an exchange with you online. Visit us at our online booth in the virtual Startup hall to talk about Kubernetes, Kubermatic Kubernetes Platform, KubeOne or just to chat. If you want to make sure that we’ve got time for a chat or show you a demo, schedule a meeting with us now. **[Schedule 1:1](https://meetings.hubspot.com/julian44/15-minute-meeting?utm_source=hs_email&utm_medium=email&_hsenc=p2ANqtz-90wCbuHLUJVeQA4dR81pJlXQS82ONBLkGrOqDPuNY28bYkwNqdu9T9HsxBip5iWypDFoAp)** ![pile of blue lego bricks](/static/iker-urteaga-tl5vy1im-ua-unsplash2_hu328d75033fb089f1fc1be7eb37ea98b7_52627_800x420_fill_q75_box_smart1-1-.jpg) **Combating Kube Chaos Without Losing Your Sanity** Anyone running an IT system for any amount of time can tell a story about a forgotten machine or three running somewhere that no one even knows about. From the server in the backroom that still runs Fortran to that EC2 instance from 2012 still on your monthly bill, the sprawl of IT systems is always increasing. It can quickly become an unmanageable mess full of snowflake servers – both physical and virtual. While many companies have processes around managing their physical and virtual environments, they face the same set of problems again when they add Kubernetes to their tech stack. **[Read More](https://www.kubermatic.com/blog/combating-kube-chaos-without-losing-your-sanity/?utm_source=hs_email&utm_medium=email&_hsenc=p2ANqtz-90wCbuHLUJVeQA4dR81pJlXQS82ONBLkGrOqDPuNY28bYkwNqdu9T9HsxBip5iWypDFoAp)** ![white poles facing downword](/static/christopher-burns-kj2sanhg-hg-unsplash_blog-post_hua0fb2dcbb7ed46324e9d178e0cf94dd0_68905_800x420_fill_q75_box_smart1-1-.jpg) **5G Core Deployment Using Kubermatic KubeOne** How can the [KubeOne](https://github.com/kubermatic/kubeone?utm_source=hs_email&utm_medium=email&_hsenc=p2ANqtz-90wCbuHLUJVeQA4dR81pJlXQS82ONBLkGrOqDPuNY28bYkwNqdu9T9HsxBip5iWypDFoAp) project be used to deploy a 5G core PoC? This blog post explores that question in depth. 5G is the next iteration of mobile technology with an emphasis on using Cloud Native technologies of which Kubernetes is meant to play an important role. KubeOne is a production grade open source Kubernetes cluster life cycle management tool. **[Read More](https://www.kubermatic.com/blog/5g-core-deployment-using-kubermatic-kubeone/?utm_source=hs_email&utm_medium=email&_hsenc=p2ANqtz-90wCbuHLUJVeQA4dR81pJlXQS82ONBLkGrOqDPuNY28bYkwNqdu9T9HsxBip5iWypDFoAp)** **Kubernetes Podcast: Talking Kubermatic with Sebastian** We open sourced Kubermatic Kubernetes Platform in June and rebranded the company to match. In the Google Kubernetes Podcast, Kubermatic co-founder and CEO Sebastian talks to Craig and Adam about the platform, how the company came about and why it was named Loodse in the first place. **[Listen](https://kubernetespodcast.com/episode/109-kubermatic/?utm_source=hs_email&utm_medium=email&_hsenc=p2ANqtz-90wCbuHLUJVeQA4dR81pJlXQS82ONBLkGrOqDPuNY28bYkwNqdu9T9HsxBip5iWypDFoAp)** **Kubermatic Webinars** Get in depth knowledge of Kubernetes and always stay up to date with our Kubermatic Webinars. You can either take part in the live webinar or visit our resource library. We are always expanding our library with the aim of covering the most relevant topics out there. **[Check Out Our Resource Library ](https://www.kubermatic.com/resources/?utm_source=hs_email&utm_medium=email&_hsenc=p2ANqtz-90wCbuHLUJVeQA4dR81pJlXQS82ONBLkGrOqDPuNY28bYkwNqdu9T9HsxBip5iWypDFoAp)** --- ## Installing Kubermatic Kubernetes Platform CE - **URL:** https://www.kubermatic.com/resources/installing-kubermatic-kubernetes-platform-ce/ - **Date:** 2022-12-01 - **Description:** In this webinar, you'll learn how to install Kubermatic Kubernetes Platform on an existing Kubernetes cluster. # Installing Kubermatic Kubernetes Platform CE ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Watch Our Webinar To Accelerate Your Cloud Native Journey With Kubermatic Kubernetes Platform As companies scale their Kubernetes environments from single cluster PoCs to real production workloads running a variety of applications across different infrastructures they quickly run into the challenge of how to manage multiple clusters in a consistent way. The Kubermatic Kubernetes Platform is an open source project that allows individuals and enterprises to manage multiple Kubernetes clusters in a declarative automated way. In this webinar, you will learn how to install Kubermatic Kubernetes Platform on an existing Kubernetes cluster. Topics covered in this session: - Architecture overview - How to setup Kubermatic master and seeds including the required infrastructure - How to deploy user clusters - Demo: Setting up Kubermatic from scratch on AWS ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Introducing KubeCarrier: Cloud Native Service Operations - **URL:** https://www.kubermatic.com/blog/announcing-our-brand-new-open-source-project-kubecarrier/ - **Date:** 2026-05-07 - **Description:** KubeCarrier is an open source service management hub to enable the centralized automation of services and applications. - **Categories:** Community - **Tags:** Open Source Projects - **Authors:** Sebastian Scheele At Kubermatic, we are highly committed to automate operations of Kubernetes across all infrastructures and up all layers. Invested in working with the open source community, we are pleased to introduce **KubeCarrier, designed to automate the provisioning and entire lifecycle management of services, applications, and API-accessible hardware devices by leveraging Kubernetes Operators.** KubeCarrier is now publically available on [Github](https://github.com/kubermatic/kubecarrier). [Operators](https://www.kubermatic.com/blog/why-kubernetes-operators-will-bring-you-to-the-next-level-of-automation/) extend the power of Kubernetes to a wide range of applications, serve as templates for automating application management, and improve scalability and repeatability – critical for deploying stateful applications in a truly cloud native way. However, as cloud native adoption accelerates, **operation teams are confronted with the complexities of service management across multiple clusters, clouds, and regions.** They struggle with enterprise-grade compliance and the operational burden involved. KubeCarrier addresses these complexities by harnessing the Kubernetes API and Operators into a central framework allowing enterprises and service providers to deliver **cloud native service management from one multi-cloud, multi-cluster hub.** With KubeCarrier, internal or external customers can immediately deploy the cloud native software and services they need, including databases, data stores, monitoring, service meshes, and other Kubernetes tooling. **One Central Hub for Cloud Native Service Management and Service Store** KubeCarrier scales up to thousands of Kubernetes clusters to deploy and manage tens of thousands of applications, functions, and resources across multiple clouds and regions. As environments grow, it ensures scalability and repeatability by making it easy to locate, inspect, and manage services across the entire platform. KubeCarrier is licensed under Apache 2.0 and provides: * Automated provisioning and entire lifecycle management of services, applications and API-accessible hardware devices * Dynamic registration of services, applications, and devices independent of cloud, region, or datacenter * Application service store * Multi-tenancy and user management with access right controls, permissions, and policies to define quotas * Automated configuration and adjustable application services * Native support for all Kubernetes Operators You can learn more about KubeCarrier by checking out our **[Documentation](https://docs.kubermatic.io/)** and joining our **[Webinar](https://www.youtube.com/watch?v=v_EG7f9UU0Y&t=7s) Introducing KubeCarrier: Operating Services the Cloud Native Way** on August 17 at 4:30 PM CEST. Also, we invite you to share your ideas and feedback on [Github](https://github.com/kubermatic/kubecarrier). By open sourcing KubeCarrier, we expand our comprehensive portfolio of open source and enterprise software solutions to empower IT teams worldwide to successfully operate their multi-cloud and edge deployments. --- ## Introduction to Pods - **URL:** https://www.kubermatic.com/blog/introduction-to-pods/ - **Date:** 2026-05-07 - **Description:** Learn more about Pods, the smallest objects that can be created in Kubernetes. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Seyi Ewegbemi **What is a Pod?** A pod is the smallest object that can be created in Kubernetes. It consists of one or more containers that are tightly coupled and is the central object type on top of which others build their functionalities. Containers in a pod are created, managed, and destroyed together. Containers in the same pod share the same resources such as storage, network, namespace, among others and can easily communicate with one another on localhost. A container in one pod can communicate with a container in another pod using the pod IP address. **The Lifecycle of a Pod** The Pod lifecycle has five possible phases. The Pod phase is the high-level summary of the current state of the Pod within its lifecycle. Below are the five Pod phases and their description * Pending: The Kubernetes system has accepted the pod but the creation of the container image(s) and/or pulling of the container image(s) from a repository is still in progress. This state includes the period when the node on which the pod will be run or scheduled is checked. * Running: The state changes to running after the pod has been scheduled on a node and the container(s) has been created and also in a running state or is in the process of starting. * Succeeded: The container(s) in the pod has terminated successfully with exit code 0 and will not restart. * Failed: The container(s) in the pod terminated in failure with non zero exit code or it was terminated by the system. * Unknown: The Pod is unreachable, thus, its state could not be determined. **Declarative and Imperative Ways of Starting a Pod** Pods can be created using either a declarative or imperative mode (check [part 2](https://www.loodse.com/blog/kubernetes-as-a-container-orchestration-tool/) of this series if you don’t know what the difference is). Creating a pod using the *imperative mode* entails using kubectl command-line tool `$kubectl run <pod name> <image> --restart=Never`. The command is passed like flags on the command line of a running cluster. In contrast, the declarative mode involves starting a pod using a configuration (YAML or JSON syntax) manifest file. The configuration file is first created and then deployed using `$kubectl create -f <YAML/JSON file name>`. More information on declarative and imperative ways of creating Kubernetes objects can be found in [part 2](https://www.kubermatic.com/blog/kubernetes-as-a-container-orchestration-tool/) of this series under Kubernetes declarative and imperative.\ **How to Manage the Lifecycle of a Pod** In this section, we will cover how to imperatively and declaratively manage Pods. A running Kubernetes cluster is needed for this exercise. Check [part 2](https://www.kubermatic.com/blog/kubernetes-as-a-container-orchestration-tool/) of this series for different ways to get a Kubernetes cluster running. **Creating a Pod Imperatively** Step 1: Create a pod with an nginx container image: ```bash $ kubectl run nginx --image=nginx --port=80 --restart=Never` pod/nginx created ``` * *nginx*: The name of the pod to be created * *--image=nginx*: The container image which is stored in the image repository * *--port=80*: Port definition which is shared by both the pod and the container * *--restart=Never*: To create a pod directly on the cluster. Creating a pod without this flag will create a deployment instead of a pod. We will expatiate more on deployment in part 4 of this series. Step 2: Check the status of the pod: ```bash $ kubectl get pods NAME READY STATUS RESTARTS AGE nginx 1/1 Running 0 12s ``` We can see that our Pod is now running on the cluster. Step 3: To learn more about the pod, check the detailed status of the pod: ```bash $ kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE nginx 1/1 Running 0 12m 10.40.0.1 node01 <none> ``` * Name → represents the name of the Pod * Ready → One out of one container has been created successfully * Status → The container is running * Restarts → The container has neither failed nor restarted * Age → The time since when the container has been up * IP → The pod IP address * Node → The node where the container is running * Nominated Node → No special assignment of a pod to a particular node Step 4: To view the description of the Pod which entails when the Pod was created, the label assigned to it, the container image running in the Pod and its ID, as well as the events associated with the Pod. ```bash $ kubectl describe pod Name: nginx Namespace: default Priority: 0 Node: node01/172.17.0.31 Start Time: Tue, 21 Jul 2020 17:15:46 +0000 Labels: run=nginx Annotations: <none> Status: Running IP: 10.244.2.3 IPs: Containers: nginx: Container ID: docker://61385d48e96f7ec6129da12ddb772f60532885e0d3c56dea8e10f70822b4cf55 Image: nginx Image ID: docker-pullable://nginx@sha256:a93c8a0b0974c967aebe868a186e5c205f4d3bcb5423a56559f2f9599074bbcd Port: 80/TCP Host Port: 0/TCP State: Running Started: Tue, 21 Jul 2020 17:15:57 +0000 Ready: True Restart Count: 0 Environment: <none> Mounts: /var/run/secrets/kubernetes.io/serviceaccount from default-token-ttjk9 (ro) Conditions: Type Status Initialized True Ready True ContainersReady True PodScheduled True Volumes: default-token-ttjk9: Type: Secret (a volume populated by a Secret) SecretName: default-token-ttjk9 Optional: false QoS Class: BestEffort Node-Selectors: <none> Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s node.kubernetes.io/unreachable:NoExecute for 300s Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 14m default-scheduler Successfully assigned default/nginx to node01 Normal Pulling 14m kubelet, node01 Pulling image "nginx" Normal Pulled 14m kubelet, node01 Successfully pulled image "nginx" Normal Created 14m kubelet, node01 Created container nginx Normal Started 14m kubelet, node01 Started container nginx ``` Step 5: Now that we have checked the status of the Pod and seen that it is healthy, we need to perform a clean up of the Pod: ```bash # where nginx is the name of the pod $ kubectl delete pods nginx pod "nginx" deleted ``` Step 6: Check to be sure that the cleanup is done and the pod has successfully been deleted ```bash $ kubectl get pod No resources found in default namespace. ``` **Creating a Pod Declaratively** Creating a pod declaratively requires the declaration of the Pod configuration using a YAML or JSON manifest file. The configuration source code comprises different properties and values. You need to be familiar with the [VIM editor](https://www.vim.org/download.php) to follow this task. However, other IDEs like Atom, visual studio among others can be used to create the configuration file. First, make sure you have a running Kubernetes cluster with kubectl command-line tool configured and connected to it. (see [part 2](https://www.kubermatic.com/blog/kubernetes-as-a-container-orchestration-tool/) of this series to get one started). Next, you need to create the configuration file. To do this, create a YAML file. You can use any name, but make sure to add the YAML extension when using YAML syntax. The correct indentation is also essential; otherwise, the file won’t work. Enter your file: `vim firstapp.yaml` Then copy and paste the configuration below into the file created above, save, and exit ```yaml apiVersion: v1 kind: Pod metadata: name: myfirst-pod labels: app: my-app spec: containers: - name: nginx-container image: nginx ``` The above configuration file defined a pod object named *myfirst-pod* with *Pod* as the value of its kind property. It will create a containerised application with *nginx-container* as the container name and nginx as the image. Note, the kind property value must be in the sentence case; otherwise, it will give an error. Once we have created the configuration file, we need to deploy it to the cluster by running the below command. ```bash $ kubectl create -f firstapp.yaml pod/myfirst-pod created ``` This will create a pod named myfirst-pod. To check the status, detailed status, description, clean up and other pod commands, use the same commands used in the imperative approach exercise above. **Multi-Container Pod** Multi-container pods are pods with more than one closely related containers that work together as a unit and share resources like inter-process communication, shared volumes, network space, etc. To create a multi-container pod, simply add another container name and image under the spec property of the previous configuration file by editing the yaml file using this command: `vim firstapp.yaml` The configuration source code will look like this: ```yaml apiVersion: v1 kind: Pod metadata: name: myfirst-pod labels: app: my-app spec: containers: - name: nginx-container image: nginx - name: redis-container image: redis ``` Save and exit the terminal. Create the multi-container pods by using the command below: ```bash $ kubectl create -f firstapp.yaml pod/myfirst-pod created $ kubectl get pods NAME READY STATUS RESTARTS AGE myfirst-pod 2/2 Running 0 26s ``` The pod named *myfirst-pod* has been created while the *2/2* under the ready column means that the two out of two containers have successfully been created and are running. To check the detailed status, description and clean up, simply use the pod commands used on our first exercise. Congratulations!!! You have successfully created, deleted, and checked the detailed information of a Pod both in a declarative and imperative manner as well as worked with multi-container pods. **Getting Logs from and Exec-ing into a Pod** Logging is a process that gives you ongoing activities in a container. It is useful for debugging and viewing the past and current events in your applications. You need to have a container running in a pod on a cluster to perform these tasks. `kubectl get pods` command will display the available pods and running containers in the cluster. You can get logs from a specific pod by running this command: `kubectl logs <pod name>` Using our previous example with the pod name *myfirst-pod*, run the below command when the pod status is in the running state. ```bash $ kubectl logs myfirst-pod /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/ /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh 10-listen-on-ipv6-by-default.sh: Getting the checksum of /etc/nginx/conf.d/default.conf 10-listen-on-ipv6-by-default.sh: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh /docker-entrypoint.sh: Configuration complete; ready for start up ``` To get only the five most recent lines of activity in a Pod run: `kubectl logs --tail=5 myfirst-pod`: ```bash $ kubectl logs --tail=5 myfirst-pod /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh\ 10-listen-on-ipv6-by-default.sh: Getting the checksum of /etc/nginx/conf.d/default.conf\ 10-listen-on-ipv6-by-default.sh: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf\ /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh\ /docker-entrypoint.sh: Configuration complete; ready for start up ``` The output here gives you the five lines of recent activities. You can specify the desired number of lines of recent activities depending on the problem you want to debug. To get the last 2 hours of logs: `kubectl logs --since=2h myfirst-pod` ```bash $ kubectl logs --since=2h myfirst-pod /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration\ /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/\ /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh\ 10-listen-on-ipv6-by-default.sh: Getting the checksum of /etc/nginx/conf.d/default.conf\ 10-listen-on-ipv6-by-default.sh: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf\ /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh\ /docker-entrypoint.sh: Configuration complete; ready for start up ``` The time can also be changed to any desired time frame. **Exec-ing into a Pod:** Exec-ing refers to the process of getting a shell into a running container by running kubectl commands. It allows the command execution on a container in a Pod. Get into a shell running container using our previous example: ```bash #where myfirst-pod is the pod name the --stdin which can also be represented as -i gives you an interactive session, and --tty which can also be represented as -t requests that you allocate TTY for that session. $ kubectl exec --stdin --tty myfirst-pod -- /bin/bash root@node01:/# # You can now run different root commands in the shell. root@node01:/# ls ## to list all the files root@node01:/# uname ## To show the name of the operating system root@node01:/# IP address ## To display the IP address root@node01:/# ps ef ## To view the running processes root@node01:/# curl localhost ## To view the container image information root@node01:/# df -kh ## To check disk utilisation root@node01:/# exit ## To exit out of the shell and end kubectl-exec ``` Summary: Knowing the nitty-gritty of a pod is essential because it forms the basis of your Kubernetes journey. However, working with or creating a Pod directly is not recommended especially if your Pod is not intended to be ephemeral or if it is running in production Instead, deployments should be used to create a pod which will give you the opportunity of using replicas and other deployment properties and values. The next part of our series will give more insight into deployment and replica sets, their features and usage as well as practice tasks. <https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#logs> [Getting started with containers](/blog/getting-started-with-containers/) <https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/> <https://kubernetes.io/docs/tasks/debug-application-cluster/get-shell-running-container/> --- ## Rancher And SUSE - A True Open Source Solution? - **URL:** https://www.kubermatic.com/blog/rancher-and-suse-a-true-open-source-solution/ - **Date:** 2026-05-07 - **Description:** Read more about how SUSE's acquisition of Rancher Labs might affect Kubernetes freedom of choice and OS vendor neutrality. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Julian Hansert The cloud native acquisition and consolidation continues. EQT owned SUSE just acquired Rancher Labs for $600M, and although Rancher revenue was not publicly disclosed, this appears to be a purchase at ~30x multiple on revenue. While EQT and SUSE celebrate the $600 million purchase as the first aggressive step towards hypergrowth via acquisition, enterprises are already sharing with us their private concerns on the future of the Rancher platform. Why is that? Let’s analyze the likely outcomes of this acquisition and its impact on customers. To deliver the ROI required for the $600M acquisition of Rancher, SUSE will have to make a decision. Beyond accessing the North American market with a Kubernetes management platform, how will SUSE evolve its product and solution messaging? And will it tie the deployment of Rancher to SUSE Enterprise Linux? **What Product Monetization And Community Playbook Will SUSE Run?** Let’s look at past market moves of both SUSE and their nearest competitor, Red Hat. There are several blueprints on how users can be tied to the underlying OS. Red Hat for example integrated important compliance features into commercial RHEL OS to hardwire the use of OpenShift to RHEL. Similarly, SUSE’s CaaS and App platforms run only on SUSE Linux. It is also important to question where Rancher’s R&D will be invested. Rancher is currently the #201st company in rank order of corporate committers to the upstream Kubernetes project (Rank 201 - as of 2020-07-12). It will be interesting to see if SUSE-owned Rancher will change their direction and start working more with the upstream community to provide more benefits to the whole kubernetes ecosystem or continue working only on their own development. **What Will Be Happening To The Rancher Users?** EQT will require a financial exit for their SUSE investment. EQT’s SUSE will be financially motivated to tie Rancher to SUSE Enterprise Linux and continue its “growth by acquisition” strategy by building out a vertical garden, akin to what Red Hat has done and what SUSE has done previously. We anticipate no immediate major change so as to prevent Rancher upsetting its customers. Running the monetization playbook won’t be done immediately, but over the course of 12-24 months, enterprise customers will find they no longer have OS vendor neutrality and freedom of choice. As a customer of Rancher, watch out for being the proverbial “frog in a pot of cool water” with the water set to heat up to a boil. If this concerns you, I’d love to discuss with you the productivity benefits of Kubernetes freedom of choice. Kubermatic as the Top 5 corporate contributor to the Kubernetes Project in 2019 is committed to providing a zero lock-in platform and empowering customer freedom of choice. Kubermatic empowers organizations worldwide to fully automate their Kubernetes and cloud native operations across multi-cloud, edge and on-prem. Our Kubermatic Kubernetes Platform makes it easy to operate thousands of Kubernetes clusters on any infrastructure. Leading enterprises including Lufthansa, Bosch, Siemens, and T-Systems trust Kubermatic on their cloud native journey. The company is headquartered in Hamburg Germany and was founded in 2016 by Sebastian Scheele and Julian Hansert. Find us at: [www.kubermatic.com](https://www.kubermatic.com) --- ## Kubernetes 101 Part 4: Kubernetes ReplicaSets & Deployments - **URL:** https://www.kubermatic.com/resources/kubernetes-101-part-4-replicasets-deployments/ - **Date:** 2026-03-17 - **Description:** Watch our webinar and learn all that you need to know about ReplicaSets & Deployments. # ReplicaSets & Deployments ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Watch the Fourth Part of Our Webinar Series and Get Started With Kubernetes ReplicaSets & Deployments. In the fourth episode of our series we focus on ReplicaSets and Deployments. ReplicaSets allow you to scale out your Pods and Kubernetes will try its best to keep them up and running. Deployments bring in rollout strategies and allow you to do zero downtime rollouts. Topics covered in this session: - Scaling your Application - Doing zero downtime rollouts - Rolling back a version ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Get Started With Kubermatic KubeOne - **URL:** https://www.kubermatic.com/resources/get-started-with-kubermatic-kubeone/ - **Date:** 2022-12-01 - **Description:** In this webinar, you will learn how to use KubeOne to create the initial cluster needed for setting up Kubermatic Kubernetes Platform. # Get Started With Kubermatic KubeOne ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Watch Our Webinar To Accelerate Your Cloud Native Journey With Kubermatic Kubernetes Platform As companies scale their Kubernetes environments from single cluster PoCs to real production workloads running a variety of applications across different infrastructures they quickly run into the challenge of how to manage multiple clusters in a consistent way. The Kubermatic Kubernetes Platform is an open source project that allows individuals and enterprises to manage multiple Kubernetes clusters in a declarative automated way. Topics covered in this session: - How to get started with KubeOne - Architecture overview - KubeOne as basis for Kubermatic Kubernetes Platform - Demo: provision, upgrading, and managing your cluster with KubeOne ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## 5G Core Deployment Using Kubermatic KubeOne - **URL:** https://www.kubermatic.com/blog/5g-core-deployment-using-kubermatic-kubeone/ - **Date:** 2026-05-07 - **Description:** Learn how to use open source Kubermatic KubeOne to deploy a 5G core Poc. - **Categories:** Products, Community - **Tags:** KubeOne, Open Source Projects - **Authors:** Christopher Adigun In this blog post, we shall be looking at how to use the [KubeOne](https://github.com/kubermatic/kubeone) project to deploy a 5G core PoC. 5G is the next iteration of mobile technology with an emphasis on using cloud native technologies of which Kubernetes is meant to play an important role. KubeOne is a production grade open source Kubernetes cluster life cycle management tool. AWS will be used for the cloud provider in this blog post. The 5G core solution that will be used is [free5gc](https://github.com/free5gc/free5gc) (version 3.0.1) which is an open source software. Free5gc has some requirements in order to achieve a successful deployment, these are: * A specific linux kernel ([5.0.0-23-generic](https://github.com/PrinzOwO/gtp5g)) is required for the GTP-U aspect (i.e. UPF). Further information about this and how to compile the 5gc kernel module can be found on the [free5gc page](https://www.free5gc.org/). * Free5gc requires static IP allocation for the service initialization and most of the CNI implementations use dynamic IP address allocation. To resolve this, an [Open vSwitch](http://www.openvswitch.org/) based [network controller](https://github.com/linkernetworks/network-controller) by sdnvortex was used to create a second network interface within the Kubernetes pod. This implies that the AWS AMI image needs to have Open vSwitch pre-installed. A specific AMI image was created for this deployment and is available publicly. In addition to Open vSwitch, a bridge interface also needs to be created before scheduling the pods. The bridge interface will enable the additional network interfaces to be able to communicate with one another. The sdnvortex controller is deployed as a daemonset but uses an init-container to create the second network interface. ***Note:*** There are several ways to achieve multiple interfaces in a Kubernetes pod, the sdnvortex controller was selected for this write-up since it is fairly easy to set up. * Because of the requirement for multiple network cards, a single worker node was used for this PoC. Using multiple worker nodes might increase the complexity way beyond that which is needed for a simple PoC, especially on public cloud environments. However, using multiple worker nodes should be easily achievable with on-prem or bare metal platforms like vSphere. Below is the diagram (from the free5gc repo) for the 5Gc deployment: ![5Gc Deployment Diagram](/static/bild-1.png) The only difference between this diagram and the PoC is that instead of using the localhost addresses, a static IP is used with the second network card inside each pod. IP details for the second network are given below: AMF - 192.168.2.2 SMF - 192.168.2.3 NRF - 192.168.2.5 AUSF - 192.168.2.4 NSSF - 192.168.2.6 UDM - 192.168.2.7 UDR - 192.168.2.8 UPF - 192.168.2.10 PCF - 192.168.2.9 Details about installing KubeOne on AWS can be found [in this blog post](/blog/running-ha-kubernetes-clusters-on-aws-using-kubeone/). A snapshot of the cluster status is given below: ![Kubernetes Cluster Status](/static/bild-2.png) After installing a KubeOne cluster with the specific AMI (5.0.0-23-generic kernel image and Open vSwitch), the Kubernetes manifests for the 5G components [can be retrieved from Bitbucket](https://bitbucket.org/infinitydon/virtual-4g-simulator/src/master/free5gc/k8s-manifests/). ***Note:*** The N3IWF was not used in this post. After applying the manifests, the status of the pods can be seen below: ![Status of the Pods](/static/bild-3.png) Let’s see the IP details for one of the pods. ![Pod IP Details](/static/bild-4.png) We can see that a second interface, eth1 with an IP address of 192.168.2.2. has been allocated by the sdnvortex controller to the AMF pod. As of now, open source 5G SA emulators are not available to simulate the connectivity of a gNB/UE to the 5G core deployment. However, we can check the logs of the SMF pod to see that it was able to initiate a PFCP connection with the UPF: ![PFCP connection](/static/bild-5.png) Sample logs from the NRF pod show communication between it and the remaining 5G core components over the service based interface: ![Sample Logs from the NRF pod](/static/bild-6.png) From the logs above, we can see that the SBI communication is over HTTP using REST (i.e. the GET and PUT statements). **Summary** In this blog post, we deployed a 5G core to a Kubernetes cluster running using KubeOne on AWS and checked its connectivity. In a future post, we will show how to install and run a 5G core on vSphere. **Where to learn more** * Kubermatic KubeOne on Github: <https://github.com/kubermatic/kubeone> * Free5gc on Github: <https://github.com/free5gc/free5gc> * About Open v Switch: <http://www.openvswitch.org/> * Sdnvortex Network Controller:<https://www.github.com/linkernetworks/network-controller> --- ## Integrated Automation for Storage and Kubernetes Clusters - **URL:** https://www.kubermatic.com/resources/integrated-automation-for-storage-and-kubernetes-clusters/ - **Date:** 2022-12-01 - **Description:** Pure Storage and Kubermatic deliver together cloud native Cluster-as-a-Service # Integrated Automation for Storage and Kubernetes Clusters ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Solution Brief ## Automate Storage and Kubernetes With Cloud Native Cluster-as-a-Service Both, storage requirements and container adoption are exploding, but a lack of automation threatens to slow the trend. Now, Kubermatic Kubernetes Platform and Pure Service Orchestrator deliver together Kubernetes-as-a-Service and Container Storage-as-a-Service to build cloud native Cluster-as-a-Service. Kubermatic and Pure Storage Cluster-as-a-Service: - Deploy and scale out cloud native applications on demand - Bring the agility you expect from the public cloud to your on-prem and multi-cloud deployments - Speed up cloud native transformation while keeping focus on application development [Read](/static/Solution%20Brief_Pure%20Storage.pdf) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Introducing KKP’s Kubernetes in Kubernetes Architecture - **URL:** https://www.kubermatic.com/resources/introducing-kkps-kubernetes-in-kubernetes-architecture/ - **Date:** 2022-12-01 - **Description:** Check out this webinar to learn how to automate thousands of Kubernetes clusters across any infrastructure. # Introducing KKP’s Kubernetes in Kubernetes Architecture ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Watch Our Webinar To Accelerate Your Cloud Native Journey With Kubermatic Kubernetes Platform In this recording, we explain how Kubermatic Kubernetes Platform’s unique Kubernetes in Kubernetes architecture provides full lifecycle management for thousands of Kubernetes clusters with automated deployments, upgrades, and policy compliance across any infrastructure. It covers the ideas driving Kubermatic Kubermatic Kubernetes Platform, the high level architecture, a demo of the platform, and a short introduction into how you can get started with the project today. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Kubernetes Podcast: Talking Kubermatic with Sebastian Scheele - **URL:** https://www.kubermatic.com/resources/kubernetes-podcast-kubermatic-with-sebastian-scheele/ - **Date:** 2024-03-22 - **Description:** Listen to this Google Kubernetes Podcast episode to learn why we decided to open source Kubermatic Kubernetes Platform # Kubernetes Podcast: Kubermatic with Sebastian Scheele ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ![](/static/resource-page_podcast_talking-kubermatic_hu_67ef683b28cb1582.jpg) Podcast ## Kubernetes Podcast: Talking Kubermatic with Sebastian Scheele In June, we made the Kubermatic Kubernetes Platform open source and rebranded the company to match. In the Google Kubernetes Podcast, Kubermatic co-founder and CEO Sebastian talks to Craig and Adam about the platform, how the company came about and why it was namend Loodse in the first place. **This podcast covers:** - Kubermatic - Kubermatic Kubernetes Platform - Company origin story [Listen](https://kubernetespodcast.com/episode/109-kubermatic/) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Combating Kube Chaos Without Losing Your Sanity - **URL:** https://www.kubermatic.com/blog/combating-kube-chaos-without-losing-your-sanity/ - **Date:** 2026-05-07 - **Description:** With multi cluster management, IT can keep track of each cluster and ensure that they comply with their policies. - **Categories:** Products - **Tags:** KKP - **Authors:** Bill Mulligan Anyone running an IT system for any amount of time can tell a story about a forgotten machine or three running somewhere that no one even knows about. **From the server in the backroom that still runs Fortran to that EC2 instance from 2012 still on your monthly bill, the sprawl of IT systems is always increasing.** It can quickly become an unmanageable mess full of snowflake servers both physical and virtual. System administrators have fought against this sprawl by managing servers like [cattle rather than pets](https://thenewstack.io/how-to-treat-your-kubernetes-clusters-like-cattle-not-pets/) and implementing workflows that required approval from department heads and conformance to security policies, like only using pre-approved images or requesting it using Jira. From our experience working with customers, many of these “systems” scale through people with each addition to the sprawl consuming more management time. In addition, while many companies have many processes around managing their physical and virtualized environments, they face this same set of problems once again as they add Kubernetes to their tech stack. **Many companies have moved past their PoC phase of Kubernetes** and quickly are finding a [new sprawl of Kubernetes clusters](https://thenewstack.io/container-sprawl-is-the-new-vm-sprawl/) popping up. **Different departments and business units are spinning up clusters in on-premises, private cloud, and public cloud environments.** Each one can be running multiple clusters provisioned through a variety of tools such as Kubespray, Kops, or managed CaaS offerings such as Google Kubernetes Engine and Azure Kubernetes Service. ![One Kubernetes cluster can quickly turn into Kube sprawl.](/static/imagelikeembed.png) **Kubernetes clusters have become the new deployment boundaries for applications.** Though namespaces provide the required isolation and boundaries, customers prefer to isolate applications by running them on different clusters. Each business function has multiple clusters running across different environments — on-premises, private cloud, self-provisioned clusters in the public cloud, managed clusters in the public cloud. Just keeping track of these clusters, let alone actually managing them poses a huge challenge to the IT and DevOps teams. To bring all the clusters to the desired and compliant state, a set of kubectl commands need to run on each cluster to ensure that they have consistent configuration, policies, quotas, and RBAC roles. Once again, doing this for each cluster is laborious and error-prone. ## Kubernetes Multi Cluster Management — A Control Plane of the Control Planes What enterprise IT needs is multi cluster management, like [Kubermatic Kubernetes Platform](http://kubermatic.io), to act as an overarching control plane of all Kubernetes clusters launched within an organization. **With multi cluster management, IT can keep track of each cluster and ensure that they comply with a set of predefined policies.** However, this cannot be just a fire and forget activity because the vast majority of IT resources are spent in Day 2 operations. The meta control plane needs to also enforce strict rules that can detect a drift in the actual cluster configuration and bring them back to the desired state of the configuration. ![Kubernetes multi-cluster management](/static/imagelikeembed-1-.png) We call it multi cluster management because it manages the control plane and worker nodes of every Kubernetes cluster. A command sent to the multi cluster manager is automatically applied to the control plane of each cluster to bring the clusters into the desired state whether that be creation, upgrading, undoing drift, or deletion. Since the multi cluster manager has visibility into each cluster, it can collect and aggregate relevant metrics related to the infrastructure and application health. Thus it becomes THE single pane of glass for both configuration and observability. **Similar to how the Kubernetes controller maintains the desired state of deployments, statefulsets, jobs, and the daemonsets, the multi cluster manager ensures that every cluster maintains the desired state of the configuration throughout its whole life cycle.** For example, if a developer needs a new cluster for testing, they will be able to self provision a new cluster based on a company blueprint using quotas defined by the operations team who have automatic observability into the cluster. If an organization has a policy, like no containers can run as root, the multi cluster manager can detect when this policy gets deleted and automatically reapplies the configuration. This is similar to how the Kubernetes controller maintains the desired count of replicas of a deployment. So, the multi cluster manager is to a Kubernetes cluster what the controller is to a deployment. There is another commonality between the Kubernetes master and a multi cluster manager. When a workload is scheduled, the placement can be influenced through the combination of labels/selectors or node affinity. A nodeSelector or NodeAfffinity ensures that the workload lands on one of the nodes that matches the criteria. Similarly, the multi cluster manager can be instructed to push a deployment, configuration, or policy only to a subset of clusters based on their labels. This mechanism closely mimics the nodeSelector pattern of Kubernetes scheduling. Similar to labeling the nodes and using a selector at the deployment to target specific node(s), we label each cluster and use a selector from the multi cluster manager to filter the target clusters. **In summary, as the number of clusters grows within an organization, a multi cluster management solution is required to take control of cluster management and avoid the chaos of IT sprawl.** At Kubermatic, we knew multi cluster management would be a problem for our customers from our first engagement with an on premise data center and production across two clouds. We designed, built, and open sourced Kubermatic Kubernetes Platform to help our customers centralize their multi cluster management and simplify their operations. ## Kubermatic Kubernetes Platform - A Multi Cluster Manager What is Kubermatic Kubernetes Platform? Simply put, it’s a Kubernetes based multi cluster management solution known for its Kubernetes in Kubernetes architecture. Though this definition is technically correct, it does not tell the whole story. Apart from being a multi cluster management solution, Kubermatic Kubernetes Platform automates many operational tasks that are critical to managing infrastructure and workloads in hybrid cloud, multi-cloud, and edge environments. The core component of Kubermatic Kubernetes Platform is actually Kuberetes itself: Kubernetes Operators and CustomResourceDefinitions are used to automate cluster life cycle management and kubectl is the command line tool. Rather than adding an additional tool to learn, Kubermatic Kubernetes Platform allows operators to reuses their existing Kubernetes knowledge of CRDs and kubectl to control cluster state. ## Kubermatic Kubernetes Platform — The Hybrid Cloud, Multi Cloud and Edge Control Plane **Kubermatic Kubernetes Platform is an open source software that can be run anywhere and used to manage Kubernetes clusters in a variety of environments including on-premises data center, AWS, Azure, GCP, and edge environments.** ![Kubermatic Kubernetes Platform works across many infrastructure providers.](/static/Kubermatic-Kubernetes-Platform.png) Kubermatic Kubernetes Platform first provisions an admin cluster using our open source tool [KubeOne](https://github.com/kubermatic/kubeone). Think of the admin cluster as the local control plane that handles the life cycle of managed clusters running on the same infrastructure. To provision additional user clusters, the user cluster control plane is created as a deployment of containers within a namespace of the admin cluster while the worker nodes are provisioned using [machine-controller](https://github.com/kubermatic/machine-controller). ![Kubermatic Kubernetes Platform Architecture](/static/wip-product-deck-kubermatic-kubernetes-platform1.jpg) To provision clusters in additional data centers or infrastructure providers, seed clusters can be set up to provide localized control plane management. They function similarly to the admin cluster, but are under its control. **Kubermatic Kubernetes Platform can launch highly available Kubernetes clusters that span multiple availability zones.** To create and manage clusters, the underlying infrastructure provider is only used to create, update, and delete servers whether physical or virtual while Kubernetes Operators take care of the rest. Technically speaking, Kubermatic Kubernetes Platform can launch a managed cluster in any programmable infrastructure that supports running Kubernetes in high availability mode. For customers that already have clusters running and would like to use other tooling for part of their infrastructure, Kubermatic Kubernetes Platform supports connecting external, unmanaged clusters to the control plane. The key difference between the two — managed vs unmanaged — is the life cycle management. While Kubermatic Kubernetes Platform can own everything from the creation and termination of managed clusters, it can only partially control the external, unmanaged clusters. Connecting external clusters allows you to have a single pane of glass over your whole Kubernetes infrastructure. ![Kubermatic Kubernetes Platform provides Kubernetes multi cluster management for hybrid, multi-cloud, and edge.](/static/imagelikeembed-2-.png) ## Key Components of Kubermatic Kubernetes Platform Apart from being a hybrid-cloud, multi-cloud, and edge multi cluster management solution for Kubernetes, Kubermatic Kubernetes Platform can manage the network policies, routing, security, cluster add ons, and configuration management of workloads deployed across clusters. Let’s take a look at the key components of Kubermatic Kubernetes Platform: * **Kubermatic Kubernetes Platform Control Plane:** This component is for multi cluster management. It’s responsible for managing the life cycle of managed clusters and the registration and un-registration of external, unmanaged clusters. * **Kubermatic Kubernetes Platform Virtualization:** Based on the open source [KubeVirt](https://kubevirt.io/) project, it allows you to run containerized and virtualized workloads side by side. In addition, it can be used to slice up large bare metal machines into smaller virtual machines to operate additional Kubernetes clusters. * **Kubermatic Kubernetes Platform Config Management:** This component based on GitOps enables a centralized mechanism to push deployments, configuration, and policies to all the participating clusters — both managed and unmanaged. A centrally accessible Git repository acts as a single source of truth for all the clusters. A Kubermatic Kubernetes Platform Config Management agent running in each cluster will monitor the change of state in a cluster. When deviated from what’s defined in the Git, the agent automatically applies the configuration which will bring the cluster back to the desired state. This works for the cluster state, policies, and cluster addons. * **Coming soon - KubeCarrier Service Platform** - An operator for operators that provides a catalog of applications and services that can be easily installed and maintained in every cluster. --- ## Kubermatic Imprint - **URL:** https://www.kubermatic.com/imprint/ - **Date:** 2024-06-19 - **Description:** Find our offices and billing address # Imprint ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) **Offices:** Kubermatic GmbH Willy-Brandt-Straße 23 20457 Hamburg Germany **Billing Address:** Kubermatic GmbH Willy-Brandt-Straße 23 20457 Hamburg Germany **Represented by:** Sebastian Scheele Julian Hansert **Contact:** Phone: +49 (40) 605907110 E-Mail: [info@kubermatic.com](mailto:info@kubermatic.com) **Commercial Register:** Amtsgericht Hamburg, HRB 143484 **Quellenangaben:** Quelle: [https://www.e-recht24.de](https://www.e-recht24.de) **Umsatzsteuer-ID:** DE306148241 **D-U-N-S:** 313710836 ## Haftungsausschluss (Disclaimer) ### Haftung für Inhalte Als Diensteanbieter sind wir gemäß § 7 Abs.1 DDG für eigene Inhalte auf diesen Seiten nach den allgemeinen Gesetzen verantwortlich. Nach §§ 8 bis 10 DDG sind wir als Diensteanbieter jedoch nicht verpflichtet, übermittelte oder gespeicherte fremde Informationen zu überwachen oder nach Umständen zu forschen, die auf eine rechtswidrige Tätigkeit hinweisen. Verpflichtungen zur Entfernung oder Sperrung der Nutzung von Informationen nach den allgemeinen Gesetzen bleiben hiervon unberührt. Eine diesbezügliche Haftung ist jedoch erst ab dem Zeitpunkt der Kenntnis einer konkreten Rechtsverletzung möglich. Bei Bekanntwerden von entsprechenden Rechtsverletzungen werden wir diese Inhalte umgehend entfernen. ### Haftung für Links Unser Angebot enthält Links zu externen Webseiten Dritter, auf deren Inhalte wir keinen Einfluss haben. Deshalb können wir für diese fremden Inhalte auch keine Gewähr übernehmen. Für die Inhalte der verlinkten Seiten ist stets der jeweilige Anbieter oder Betreiber der Seiten verantwortlich. Die verlinkten Seiten wurden zum Zeitpunkt der Verlinkung auf mögliche Rechtsverstöße überprüft. Rechtswidrige Inhalte waren zum Zeitpunkt der Verlinkung nicht erkennbar. Eine permanente inhaltliche Kontrolle der verlinkten Seiten ist jedoch ohne konkrete Anhaltspunkte einer Rechtsverletzung nicht zumutbar. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Links umgehend entfernen. ### Urheberrecht Die durch die Seitenbetreiber erstellten Inhalte und Werke auf diesen Seiten unterliegen dem deutschen Urheberrecht. Die Vervielfältigung, Bearbeitung, Verbreitung und jede Art der Verwertung außerhalb der Grenzen des Urheberrechtes bedürfen der schriftlichen Zustimmung des jeweiligen Autors bzw. Erstellers. Downloads und Kopien dieser Seite sind nur für den privaten, nicht kommerziellen Gebrauch gestattet. Soweit die Inhalte auf dieser Seite nicht vom Betreiber erstellt wurden, werden die Urheberrechte Dritter beachtet. Insbesondere werden Inhalte Dritter als solche gekennzeichnet. Sollten Sie trotzdem auf eine Urheberrechtsverletzung aufmerksam werden, bitten wir um einen entsprechenden Hinweis. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Inhalte umgehend entfernen. ## Datenschutzerklärung ### Datenschutz Die Betreiber dieser Seiten nehmen den Schutz Ihrer persönlichen Daten sehr ernst. Wir behandeln Ihre personenbezogenen Daten vertraulich und entsprechend der gesetzlichen Datenschutzvorschriften sowie dieser Datenschutzerklärung. Die Nutzung unserer Webseite ist in der Regel ohne Angabe personenbezogener Daten möglich. Soweit auf unseren Seiten personenbezogene Daten (beispielsweise Name, Anschrift oder E-Mail-Adressen) erhoben werden, erfolgt dies, soweit möglich, stets auf freiwilliger Basis. Diese Daten werden ohne Ihre ausdrückliche Zustimmung nicht an Dritte weitergegeben. Wir weisen darauf hin, dass die Datenübertragung im Internet (z.B. bei der Kommunikation per E-Mail) Sicherheitslücken aufweisen kann. Ein lückenloser Schutz der Daten vor dem Zugriff durch Dritte ist nicht möglich. ### Datenschutzerklärung für die Nutzung von Google Analytics Diese Website nutzt Funktionen des Webanalysedienstes Google Analytics. Anbieter ist die Google Ireland Ltd, Gordon House, Barrow Street, Dublin 4, Ireland (“Google”). Google Analytics verwendet sog. “Cookies”. Das sind Textdateien, die auf Ihrem Computer gespeichert werden und die eine Analyse der Benutzung der Website durch Sie ermöglichen. Die durch den Cookie erzeugten Informationen über Ihre Benutzung dieser Website werden in der Regel an einen Server von Google in den USA übertragen und dort gespeichert. Im Falle der Aktivierung der IP-Anonymisierung auf dieser Webseite wird Ihre IP-Adresse von Google jedoch innerhalb von Mitgliedstaaten der Europäischen Union oder in anderen Vertragsstaaten des Abkommens über den Europäischen Wirtschaftsraum zuvor gekürzt. Nur in Ausnahmefällen wird die volle IP-Adresse an einen Server von Google in den USA übertragen und dort gekürzt. Im Auftrag des Betreibers dieser Website wird Google diese Informationen benutzen, um Ihre Nutzung der Website auszuwerten, um Reports über die Websiteaktivitäten zusammenzustellen und um weitere mit der Websitenutzung und der Internetnutzung verbundene Dienstleistungen gegenüber dem Websitebetreiber zu erbringen. Die im Rahmen von Google Analytics von Ihrem Browser übermittelte IP-Adresse wird nicht mit anderen Daten von Google zusammengeführt. Sie können die Speicherung der Cookies durch eine entsprechende Einstellung Ihrer Browser-Software verhindern; wir weisen Sie jedoch darauf hin, dass Sie in diesem Fall gegebenenfalls nicht sämtliche Funktionen dieser Website vollumfänglich werden nutzen können. Sie können darüber hinaus die Erfassung der durch das Cookie erzeugten und auf Ihre Nutzung der Website bezogenen Daten (inkl. Ihrer IP-Adresse) an Google sowie die Verarbeitung dieser Daten durch Google verhindern, indem sie das unter dem folgenden Link verfügbare Browser-Plugin herunterladen und installieren: [http://tools.google.com/dlpage/gaoptout?hl=de](http://tools.google.com/dlpage/gaoptout?hl=de) ### Datenschutzerklärung für die Nutzung von Twitter Auf unseren Seiten sind Funktionen des Dienstes X eingebunden. Diese Funktionen werden angeboten durch die X Corp., 1355 Market Street, Suite 900, San Francisco, CA 94103, USA. Durch das Benutzen von X und der Funktion “Re-Tweet” werden die von Ihnen besuchten Webseiten mit Ihrem Account bei X verknüpft und anderen Nutzern bekannt gegeben. Dabei werden auch Daten an die X Corp. übertragen. Wir weisen darauf hin, dass wir als Anbieter der Seiten keine Kenntnis vom Inhalt der übermittelten Daten sowie deren Nutzung durch X erhalten. Weitere Informationen hierzu finden Sie in der Datenschutzerklärung von Twitter unter [http://x.com/de/privacy](http://x.com/de/privacy). Ihre Datenschutzeinstellungen bei Twitter können Sie in den Konto-Einstellungen unter [http://x.com/settings/account](http://x.com/settings/account) ändern. --- ## Privacy Policy - **URL:** https://www.kubermatic.com/privacy/ - **Date:** 2024-12-02 - **Description:** This policy applies to the website of Kubermatic GmbH. # Privacy Policy ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Privacy Policy ### 1. Introduction In this Privacy Policy, we will inform you about the processing of your personal data and your data protection rights within the scope of your contact to Kubermatic. Your privacy is an important concern to us. We exercise great care in the protection of your personal data and their strictly confidential processing. Your personal data will be exclusively processed in compliance with the applicable provisions under data protection law, rules, and regulations. We will not use your data for anything other than the stated purposes. Kubermatic is subject to the provisions of the European Union’s General Data Protection Regulation (GDPR), the German Federal Data Protection Act (FDPA), the German Digital Services Act (DDG) as well as further data protection provisions, and has implemented appropriate technical and organizational measures to ensure that the provisions of applicable data protection laws are observed. ### 2. Data Controller and Privacy Officer Data controller for all processing activities in the context of your business relationship to Kubermatic, unless stated otherwise, is: Kubermatic GmbH Willy-Brandt-Straße 23 20457 Hamburg Email: [info@kubermatic.com](mailto:info@kubermatic.com) Please do not hesitate to contact us if you have any questions or suggestions regarding data protection issues. Our data processing is audited and monitored regularly by our designated Data Protection Officer. To contact our Data Protection Officer please write to [privacy@kubermatic.com](mailto:privacy@kubermatic.com). ### 3. Processing Personal Data Personal data means any information relating to an identified or identifiable natural person (hereinafter referred to as a “data subject”); an identifiable natural person is anyone who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier, or to one or more specific factors. ### 4. Purpose and Details of Data Processing Operations #### Data processing on this Website Each time a user visits a page on the Kubermatic website and each time a file is accessed, data about this event is stored in a log file. Depending on the type of access log used, the log file may contain the following information: - The IP address of the device that requested the information - The name of the requested file - The date and time of the request - The requesting device’s desired method of access/functions - The web server’s access status - The URL from which the file was requested - The device’s operating system and browser type or browser settings Usage profiles that link IP addresses with personal data are not created. Exceptions only apply if expressly stated in this Privacy Policy. The data stored in these log files is used exclusively for the purposes of identifying and tracking unauthorized access attempts/accesses to the web server and for statistical analyses, such as the number of visitors and the popularity of a page. Such analyses are only carried out by authorized employees of Kubermatic. **Contact Forms** If you contact us via our contact form, your data from the form will be processed for your request. The legal basis for the data transfer to us is your consent according to Art. 6 (1) a GDPR. Personal data entered into forms on our website will be transmitted to Kubermatic via a secure connection in encrypted form. You can withdraw your consent at any time with effect for the future. **Newsletter** The purpose of sending the newsletter is to provide information about new products and services of our company. We send newsletters to our customers on the basis of our legitimate interests according to Art. 6 (1) f GDPR in conjunction with Rec. 47 sentence 7 GDPR or on the basis of consent according to Art. 6 (1) a GDPR if you subscribe to a newsletter. The data will not be passed on to third parties. In the case of a newsletter subscription, the so-called double opt-in procedure is used, the request for the newsletter must be actively confirmed by you once again by clicking on the link of the e-mail sent to you. You can unsubscribe at any time by clicking on the “unsubscribe” link. **Use of Cookies** This website uses storage technologies (“cookies” and/or your browser’s memory) to enable a record of your use of the website. The information generated by cookies about your usage patterns on this website is used to allow us to identify your web browser. If the use of storage technologies on your end device is necessary for the functionality of the website, we use this technology on the basis of our legitimate interests. The legal basis for data processing is then Art. 6 (1) f GDPR (legitimate interest) in conjunction with § 25 (2) No. 2 New German Telecommunications-Telemedia Data Protection Act (TDDDG). If a use of cookies takes place, which are not necessary for the operation of the website, we ask for your consent in advance; the legal basis for the data processing is Art. 6 (1) lit. a GDPR, § 25 (1) New German Telecommunications-Telemedia Data Protection Act (TDDDG). The cookies will be deleted after two years at the latest. You may refuse the use of cookies by selecting the appropriate settings on your browser, however please note that if you do this you may not be able to use the full functionality of this website. The data collection is anonymised; the collected data cannot be related to your person. **Why do we use cookies?** Cookies and similar technologies are very small text documents or pieces of code that often contain a unique identification code. When you visit a website or use a mobile application, a computer asks your computer or mobile device for permission to save this file on your computer or mobile device and gain access to information. Information collected through cookies and similar technologies may include the date and time of the visit and how you use a particular website or mobile application. The cookies ensure that we can see how our website is used and how we can improve it. Furthermore, depending on your preferences our own cookies may be used to present you with targeted advertisements that match your personal interests. **What type of cookies do we use?** *Necessary cookies* These cookies are necessary for the website to function properly. Some of the following actions can be performed by using these cookies.- Store articles in a shopping cart for online purchases- Save your cookie preferences for this website- Saving language preferences- Log in to our portal. We need to check whether you are logged in. *Performance cookies* These cookies are used to gather statistical information about the use of our website, also called analytics cookies. We use this data for performance and website optimization. *Functional cookies* These cookies enable more functionality for our website visitors. These cookies can be set by our external service providers or our own website. The following functionalities may or may not be activated when you accept this category. - Live chat services - Watch online videos - Social media sharing buttons - Login to our website with social media *Advertising / tracking cookies* These cookies are set by external advertising partners and are used for profiling and tracking data across multiple websites. If you accept these cookies, we may show our advertisements on other websites based on your user profile and preferences. These cookies also save data about how many visitors have seen or clicked on our advertisements in order to optimize advertising campaigns **How can you switch off or remove cookies?** You can choose to opt out of all but the necessary cookies. In the settings of the browser, you can change the settings to ensure that cookies will be blocked. Most browsers provide you with an explanation on how to do this in the so-called ‘help-function’. However, if you block the cookies, it is possible that you will not be able to enjoy all the technical features our website has to offer and it may negatively affect your user experience. We have made it easy to manage your consents. **The services we use on our website** *Amazon CloudFront* This website uses the Cloudfront Content Delivery Network (CDN). This is a service provided by Amazon Web Services Inc, 410 Terry Avenue North, Seattle, WA 98109-5210. The Cloudfront CDN makes duplicates of a website’s data available on various Amazon Web Services (AWS) servers distributed around the world. This provides faster website load times, increased resiliency, and increased protection against data loss. Some of the images and videos embedded on this website are retrieved from Cloudfront CDN when the page is accessed. Through this retrieval, information about your use of our website (such as your IP address) is transmitted to Amazon’s servers in other EU countries and stored there. This happens as soon as you enter our website. The use of Amazon Web Services and the Amazon CDN Cloudfront is done in the interest of a higher reliability of the website, increased protection against data loss and a better loading speed of this website. This constitutes a legitimate interest within the meaning of Art. 6 (1) f GDPR. You can find out more about the data protection measures of Amazon Web Services at: [https://aws.amazon.com/de/compliance/data-protection/](https://aws.amazon.com/de/compliance/data-protection/). The current privacy policy of Amazon Web Services can be found at: [https://aws.amazon.com/de/privacy/](https://aws.amazon.com/de/privacy/). *DoubleClick* We use DoubleClick, a web analytics service from Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA (“Google”) to activate ads relevant to users, improve campaign performance reports, or to prevent a user from seeing the same ads more than once. Google uses a cookie ID to track which ads are displayed in which browser and to prevent them from being displayed more than once. Data processing is based on your consent referring to Art. 6 (1) a GDPR. *Google Analytics* This website uses Google Analytics, a web analytics service provided by Google Ireland Ltd, Gordon House, Barrow Street, Dublin 4, Ireland (“Google”). The legal basis for this processing is your consent in accordance with Art. 6 (1) a GDPR. Google Analytics also uses “cookies”, which are text files set on your device, to help the website analyse how users use the website. It cannot be excluded that the information generated by the cookie about your use of this website is transmitted to a Google server in the USA and stored there. Data is only transferred to the USA if the requirements of Art. 44 et seq. GDPR are fulfilled. The transfer of personal data to Google Servers in the USA is based on the EU-U.S.-Data Privacy Framework. Via [https://www.dataprivacyframework.gov/s/participant-search](https://www.dataprivacyframework.gov/s/participant-search) you may check the participation of Google LLC. in the EU-U.S.-Data Privacy Framework. On behalf of the operator of this website, Google will use this information for the purpose of evaluating your use of the website, compiling reports on website activity and providing other services relating to website activity and internet usage to the website operator. The IP address transmitted by your browser as part of Google Analytics will not be merged with other Google data. The user data will be deleted after 24 months. You can revoke your consent at any time with effect for the future and prevent the use of data by Google by downloading and activating the available browser plugin: [http://tools.google.com/dlpage/gaoptout?hl=en](http://tools.google.com/dlpage/gaoptout?hl=en). You may also refuse the use of cookies by selecting the appropriate settings on your browser, however please note that if you do this you may not be able to use the full functionality of this website. Find more information on data protection at Google at [https://policies.google.com/privacy](https://policies.google.com/privacy). *Google Tag Manager* This website uses Google Tag Manager. This is a service provided by Google Ireland Ltd, Gordon House, Barrow Street, Dublin 4, Ireland (“Google”). It is used to manage the Google services on our website. The legal basis for this processing is consent in accordance with Art. 6 (1) (a) GDPR. As part of this processing, it cannot be ruled out that this information will be transferred to a Google server in the USA. Data will only be transferred to the USA if the requirements of Art. 44 et seq. GDPR are fulfilled. The transfer of personal data to the USA has been declared permissible by the EU-U.S. Data Privacy Framework. The terms of use of Google [https://policies.google.com/terms](https://policies.google.com/terms), [https://marketingplatform.google.com/about/analytics/tag-manager/use-policy/](https://marketingplatform.google.com/about/analytics/tag-manager/use-policy/) and the privacy policy of Google [https://policies.google.com/privacy](https://policies.google.com/privacy) apply. *Hubspot* We use the web analytics services of Hubspot, 25 First Street, 2nd Floor Cambridge, MA 02141, USA, on our website based on your consent (Art. 6 (1) a GDPR). For this purpose, Hubspot collects and stores on our behalf certain usage data (e.g. which sites you navigate to, how long you spend on these sites, how often you return to our website) attributed to an anonymous identifier. This usage data is then used to generate non-personalized analyses of website usage for us. Usage data may be processed by our cookie suppliers on servers in the United States of America. To ensure an adequate level of data protection, we entered into a Data Processing Agreement including EU-Standard Contractual Clauses with Hubspot. On top, Hubspot is listed to the [Data Privacy Framework](https://www.dataprivacyframework.gov/s/participant-search). *Microsoft Clarity* We work with Microsoft Clarity to understand how you use and interact with our website. We use behavioural metrics, heatmaps and session replays to improve and market our products/services. Website usage data is collected using tracking technologies to determine the popularity of products/services and online activities. We also use this information to optimise the website. The legal basis for the processing is your consent in accordance with Art. 6 para. 1 a GDPR. When interacting with our website and on the basis of your consent pursuant to Art. 6 para. 1 lit. a GDPR, your data will be transmitted to the independent controller Microsoft Ireland Operations Ltd, One Microsoft Place, South County Business Park, Leopardstown, Dublin 18, Ireland. As part of this processing, it cannot be ruled out that your data will be transferred to a server in the USA. Data will only be transferred to the USA if the requirements of Art. 44 et seq. GDPR are fulfilled. For more information on how Microsoft collects and uses your data, please refer to the Microsoft Privacy Policy. You can revoke your consent at any time with effect for the future via the [Privacy-Settings](#). You can also use your internet browser to control the use of cookies and withdraw your consent by deleting or blocking cookies. Further you can adjust your settings for adverts by Microsoft here. *Weglot* This website uses the translation service Weglot (Weglot SAS, 7 cité Paradis 75010 Paris, France) to display our website in different languages and thus to be able to address international interested parties. This tool serves the functionality of our website and is used on the basis of Art. 6 para. 1 lit. f GDPR (legitimate interests). Further information on the use of Weglot can be found at: [https://weglot.com/privacy/](https://weglot.com/privacy/). *LinkedIn Insights Tag* We use LinkedIn Insights Tag on our website, a service provided by LinkedIn Ireland Unlimited Company, Wilton Place, Dublin 2, Ireland. The purpose of its use is to analyze the success of our advertising on LinkedIn. Through the LinkedIn Insight Tag, data about visitors to the website is collected: URL, referrer URL, IP address, device and browser properties (user agent), and timestamp. IP addresses are shortened or (if used to reach members across devices) hashed. Members’ direct identifiers are removed within seven days to pseudonymize the data. This remaining pseudonymized data is then deleted within 180 days. For us, the processing is not attributable to your person (IP masking). During use, a transmission of data to the LinkedIn Corporation in the USA is not excluded. A data transfer to the USA only occurs if the requirements of Art. 44 et seq. GDPR are fulfilled. The legal basis for the data processing is your consent according to Art. 6 (1) (a) GDPR. You can withdraw your consent at any time with effect for the future in the settings of our consent tool or object to the processing via this link: [https://www.linkedin.com/psettings/guest-controls/retargeting-opt-out](https://www.linkedin.com/psettings/guest-controls/retargeting-opt-out) Furthermore, if you have a LinkedIn profile, you can choose to set the data collection centrally for all websites with LinkedIn technology for your profile in the LinkedIn settings: [https://www.linkedin.com/psettings/enhanced-advertising](https://www.linkedin.com/psettings/enhanced-advertising) Information on data protection at LinkedIn can be found here: [https://www.linkedin.com/legal/privacy-policy](https://www.linkedin.com/legal/privacy-policy) *Google Ads* For the optimization of our advertising we use Google Adwords Remarketing tags from Google (Google Ireland Limited, Gordon House, Barrrow Street, Dublin 4, Ireland). The legal basis for the use of your data for analysis of our website and economic optimization of our service is your consent based on Art. 6 (1) (a) GDPR. The data processing with Google Ads serves to ensure that advertising is only shown to interested persons. In the context of remarketing, code, small graphics and cookies from Google are integrated in our website. This makes it possible to trace which websites you visit outside our site and what content you are interested in. This enables us to track which Google advertising has led to actions/orders from users on our site. We only receive the number of users who have clicked on an advertisement and cannot use this information to identify you. Within the scope of data processing, it is possible that data may be transferred to a Google server in the USA. A data transfer to the USA shall only be carried out if the requirements of Art. 44 et seq. GDPR are fulfilled. The content is processed pseudonymously and is not combined with other data such as your name or e-mail address, unless you allow Google to do so via your user account settings. Further information can be obtained from Google’s privacy policy: [https://www.google.com/policies/privacy](https://www.google.com/policies/privacy). If you have a Google account, you can manage the settings for the Google services and thus also object to the data processing: [https://policies.google.com/technologies/ads](https://policies.google.com/technologies/ads). Otherwise, [click here](#) to deactivate Google Adwords Remarketing in the Privacy-Settings. *Leadfeeder* On our website, we use the tool Leadfeeder, operated by Dealfront Group GmbH and its affiliates. The tool collects information about visitors to the website and identifies business IP addresses. To do this, a tracking code is placed on our website, allowing Leadfeeder to recognize the business IP addresses of our visitors. These IP addresses are then matched against a global database of companies. Leadfeeder only collects business-related information. The information obtained through Lead feeder enables us to create statistics about visits to our website, which we use for optimization and measuring reach. The legal basis for the use of your data for analysis of our website and economic optimization of our service is your consent based on Art. 6 (1) (a) GDPR. For more information, please visit: [https://www.leadfeeder.com/privacy/](https://www.leadfeeder.com/privacy/). You can revoke your consent at any time with effect for the future via our [Privacy-Settings](#). You can also use your internet browser to control the use of cookies and withdraw your consent by deleting or blocking cookies. *Google Maps* This website uses Google Maps, a service provided by Google Ireland Ltd., Gordon House, Barrow Street, Dublin 4, Ireland (“Google”). The legal basis for this processing is your consent according to Art. 6 (1) (a) GDPR pursuant to Art. 49 (1) sentence 1 (a) GDPR. At least the IP address, URL (internet address) of our website and date/time of use are transmitted to Google. The possibility that this data might be transmitted to a Google server in the USA cannot be excluded. Data transfer to the USA only occurs if the requirements of Art. 44 et seq. GDPR are fulfilled. According to the European Commission, personal data transferred from the EU to US companies participating in the EU-U.S. Data Privacy Framework (DPF), including Google Inc., has been deemed reasonably secure. As a visitor, you enter a direct user relationship with Google when using Google Maps. You can find more information on this in Google’s detailed privacy policy at: [https://policies.google.com/privacy?hl=en-GB](https://policies.google.com/privacy?hl=en-GB). *Use of Google ReCaptcha* We use Google ReCaptcha for protection against bots (human/machine distinction). We only establish the connection to this Google service with your consent (legal basis Art. 6 (1) (a) GDPR). Google ReCaptcha is provided by Google Ireland Ltd., Gordon House, Barrow Street, Dublin 4, Ireland (““Google””). The possibility that your data might be transmitted to a Google server in the USA (Google LLC, 1600 Amphitheatre Parkway, Mountain View, CA 94043) cannot be excluded. Data transfer to the USA only occurs if the requirements of Art. 44 et seq. GDPR are fulfilled. Google´s terms of use ([https://policies.google.com/terms?hl=en-GB](https://policies.google.com/terms?hl=en-GB)) and privacy policy ([https://policies.google.com/privacy?hl=en-GB](https://policies.google.com/privacy?hl=en-GB)) apply. Opting out is possible via your Google account: [https://adssettings.google.com/authenticated](https://adssettings.google.com/authenticated). #### Data Processing in Webinars If you have registered for one of our webinars, we will process your data for the purposes of your participation based on Art. 6 (1) b GDPR. Your personal data entered into the registration form will be transmitted to Kubermatic via a secure connection in encrypted form. In order to invite you to take part in other relevant Webinars, we process your contact data based on Art. 6 (1) f GDPR. You may contact us at any time to inform us about your interest to unsubscribe from further webinars. #### Data Processing on Social Media Platforms Kubermatic may provide social media features that enable you to share information with your social networks and interact with Kubermatic on various social media websites. Your use of these features may result in the collection or sharing of information about you, depending on the feature. We encourage you to review the privacy policies and settings on the social media websites with which you interact to make sure you understand the information that may be collected, used, and shared by those websites. Our websites may make chat rooms, forums, blogs, message boards, and/or news groups available to its users. Remember that your comments and posts become publicly available, and we urge you to exercise discretion when submitting such content. Our websites may contain links to other websites. Kubermatic does not control and is not responsible for the information collected by websites that can be reached through links from our websites. If you have questions about the data collection procedures of linked websites, please contact the organizations that operate those websites directly. *Facebook* With Meta Platforms Ireland Ltd., 4 Grand Canal Square, Grand Canal Harbour, Dublin 2, Ireland, a Joint Control Agreement has been completed, which you have access to on [https://www.facebook.com/legal/terms/dataprocessing](https://www.facebook.com/legal/terms/dataprocessing) [https://www.facebook.com/legal/terms/page\_controller\_addendum](https://www.facebook.com/legal/terms/page_controller_addendum) Meta Platforms Ireland Ltd. assumes the primary responsibility acc. to the European Data Protection Regulation (GDPR). To learn more about the Facebook privacy statement, please visit [https://www.facebook.com/privacy/explanation](https://www.facebook.com/privacy/explanation) The purpose of data processing on our fan page is to provide information on our products and services and simultaneously allowing users a targeted interaction with us. The data processing is legally based on Art. 6 (1) f GDPR. Our legitimate interest is in particular our economic interest, the exchange of information with our users and to communicate with them. Data disclosure to authorities requires the existence of overriding statutory provisions. If pictures are published; this is done via consent (legal basis: Art. 6 (1) a GDPR), on basis of a contractual agreement (legal basis: Art. 6 (1) b GDPR) and, in exceptional cases, on basis of legitimate interests. Legal basis: Art. 6 (1) f GDPR. **Use of Facebook-Insights** We operate online advertisement on Facebook and use Facebook Insights in order to evaluate the behavior of our target group resulting from interaction with our website. The precise target group advertising is a legitimate interest of our company. Facebook users are informed; the main responsibility for such data collection lies with Meta Platforms Ireland Ltd. Conflicting interests of users are not overriding (publication of individual target group optimized advertising). Our legal basis is Art. 6 (1) f GDPR. *Instagram* Instagram is a service provided by Meta Platforms Ireland Ltd. A Joint Controller Agreement (JCA) has been entered to with Meta Platforms Ireland Ltd., 4 Grand Canal Square, Grand Canal Harbour, Dublin 2, Ireland which you can access here: [https://www.facebook.com/legal/terms/dataprocessing](https://www.facebook.com/legal/terms/dataprocessing) [https://www.facebook.com/legal/terms/page\_controller\_addendum](https://www.facebook.com/legal/terms/page_controller_addendum) Meta Platforms Ireland Ltd. assumes primary responsibility under the General Data Protection Regulation (GDPR). To learn more about Instagram´s privacy policy, please visit: [https://privacycenter.instagram.com/policy/](https://privacycenter.instagram.com/policy/) The purpose of data processing on our Instagram account is to provide information about our products and services in addition to enabling to interact directly with us. The legal basis for the data processing is Art. 6 (1) f GDPR. Our legitimate interest is, in particular, our commercial interest in sharing information with our users and being able to communicate with them. Data will only be transferred to the authorities if overriding legal provisions apply. If we publish images of individuals, this is done with consent (legal basis: Art. 6 (1) (a) GDPR), based on a written contractual agreement (legal basis: Art. 6 (1) (b) GDPR) and in exceptional cases based on legitimate interest (legal basis: Art. 6 (1) f GDPR) pursuant to Section 23 (1) No. 3 of the German law on copyright in works of art and photography). **Use of Instagram Insights** We place advertisements on Instagram and use Instagram Insights to evaluate the behaviour of our target group in the context of their interaction with our website. The targeting of advertising is a legitimate interest of our company (legal basis: Art. 6 (1) (f) GDPR). Instagram users are informed about this; the responsibility for such data collection lies primarily with Meta Platforms Ireland Ltd. Conflicting interests of users are not overriding (publication of individual target group optimised advertising). *LinkedIn* We use our LinkedIn Company Page to provide information about our company, our products and services, combined with the opportunity for users to interact directly with us. The legal basis is our legitimate interest pursuant to Art. 6 (1) (f) GDPR. Our legitimate interest consists primarily in our business interest in sharing information about our company with customers, interested parties, applicants and third parties as well as being able to contact them. If we publish images of persons, this is done with their consent (legal basis: Art. 6 (1) (a) GDPR) or on the basis of a contractual assignment of the rights of use (legal basis: Art. 6 (1) (b) GDPR). We process personal data through our LinkedIn Company Page for the purpose of establishing contact, publicising our company and providing information. Our company processes your personal data when you use the messaging, commenting and posting functions. Your data will only be provided to authorities if there are overriding legal provisions. When using LinkedIn, each user enters a direct contractual relationship with LinkedIn Ireland Unlimited Company, Wilton Place, Dublin 2, Ireland. How LinkedIn processes user data can be viewed in their data protection information: [https://www.linkedin.com/legal/privacy-policy?trk=homepage-basic\_footer-privacy-policy](https://www.linkedin.com/legal/privacy-policy?trk=homepage-basic_footer-privacy-policy). Please note that the possibility of user data being processed on systems outside the European Union cannot be ruled out. LinkedIn has undertaken to comply with EU data protection standards. Data will only be transferred to systems outside the EU if the requirements of Art. 44 et seq. GDPR are complied with. You can find out more at: [https://www.linkedin.com/help/linkedin/answer/a1343190?trk=microsites-frontend\_legal\_privacy-policy&lang=en-us&intendedLocale=und](https://www.linkedin.com/help/linkedin/answer/a1343190?trk=microsites-frontend_legal_privacy-policy&lang=en-us&intendedLocale=und). **Use of Page Insights** When a LinkedIn user visits, follows or engages with our LinkedIn page, LinkedIn processes personal data in order to make the page views available to us. In particular, LinkedIn processes data that the user has provided to LinkedIn in their profile, such as the position, country, industry, period of employment, company size and employment status. In addition, LinkedIn processes information about how a user has interacted with our company page, e.g. whether a user is a follower. Data processing is carried out on the basis of our legitimate interests in customising our company profile for specific target groups. Conflicting legitimate interests of users (display of individual target group-optimised advertising) are not overriding. Together with LinkedIn, we are a joint controller for the Page Insights in accordance with Art. 26 GDPR. LinkedIn users are informed of this; the responsibility for data collection lies primarily with LinkedIn. A Joint Controller Addendum has been concluded with LinkedIn, which you can find here: [https://legal.linkedin.com/pages-joint-controller-addendum](https://legal.linkedin.com/pages-joint-controller-addendum). *X* X is a service provided by X Corp., 1355 Market Street, Suite 900, San Francisco, CA 94103 U.S.A. If we process data with X, this is done based on the purpose and legal basis outlined below. There is no transfer of data to X, such as IP addresses, due to the embedding of tweets on homepages or similar. However, we may retweet tweets from you, reply to tweets from you or write tweets that refer to you or your X account. In this respect, your public data on X may be made available to followers of our site. The purpose of data processing on our X site is to provide information about products, services and news, combined with the possibility for users to interact with us in a targeted manner. The legal basis for the data processing is our legitimate interest (Art. 6 (1) f GDPR) on sharing information with our users and being able to communicate with them. If we publish images of individuals, this is done via consent (legal basis: Art. 6 (1) a GDPR), based on a contractual agreement (legal basis: Art. 6 (1) b GDPR), and in exceptional cases based on legitimate interests (legal basis: Art. 6 (1) f. GDPR) to publish information about our services and events. **Data processed by X** We have no influence on the type and scope of the data processed by X Corp. or the transfer of the data to third parties. Furthermore, there are no control options for us. It is not excluded that data from users is processed on systems outside the European Union. Retrieval of public tweets is possible worldwide. In this context, we would like to point out that you use the services provided by X Corp. and all associated functions (e.g., sharing and rating content) takes place on your own responsibility. Information about the data processing carried out by X Corp. and the corresponding purposes pursued can be found in the data protection guidelines of X Corp. here: [https://twitter.com/en/privacy](https://twitter.com/en/privacy) It is possible for you to restrict the processing of your data by X. For that purpose, you can open the general settings of your X account and change your privacy settings. You can also change certain settings for your mobile devices (e.g., smartphones, tablets, etc.) so that X only has limited access to your contact data, location data, calendar data or photos. These setting options differ depending on the operating system used on your mobile device. For more information and assistance, please refer to the following links: [https://help.x.com/en/personalization-data-settings](https://help.x.com/en/personalization-data-settings) To view the processed data, obtain information about their use and download the corresponding data as an archive, you can follow this link. [https://help.x.com/en/managing-your-account/accessing-your-X-data](https://help.x.com/en/managing-your-account/accessing-your-X-data) To contact X, you can follow this link: [https://help.x.com/en/forms/privacy](https://help.x.com/en/forms/privacy) *YouTube* We use a YouTube channel of Google Ireland Limited, Gordon House, 4 Barrow St, Dublin, D04 E5W5. The purpose of data processing on our YouTube channel is to provide information about products, services and news, combined with the possibility for users to interact with us in a targeted manner. The legal basis for the data processing is Art. 6 (1) f GDPR. Our legitimate interest is in particular our business interest to share information with the visitors of the YouTube channel and to be able to communicate with them. The YouTube service is based on the following data processing agreement with Google Ireland Ltd.: [https://www.youtube.com/t/terms\_dataprocessing](https://www.youtube.com/t/terms_dataprocessing). Google Ireland Limited, Gordon House, Barrow Street, Dublin 4, Ireland is responsible for the collection and further processing of personal user data on YouTube channels. Please note that YouTube collects and processes certain information about your visit to our YouTube channel even if you do not have a YouTube user account or are not logged in to YouTube. For us as the provider of this YouTube channel, only your public profile on YouTube is visible. The kind of information visible for us depends on your settings in your profile. For information about the processing of personal data by YouTube, please refer to YouTube’s privacy policy at [https://policies.google.com/privacy?hl=de&gl=de](https://policies.google.com/privacy?hl=de&gl=de). If we publish images of individuals, this is done via consent (legal basis: Art. 6 (1) a GDPR), based on a contractual agreement (legal basis: Art. 6 (1) b GDPR) and in exceptional cases based on legitimate interests (legal basis: Art. 6 (1) f. GDPR. **YouTube Analytics** We also process your activities on our YouTube channel with the help of the statistics service YouTube Analytics. This process helps us to understand our video and channel performance and optimize our channel and our content. This process is consistent with the purpose of data processing described below. Anonymous statistics are created based on your activities. Among other things, we can gain insights into the interactions and activities of our subscribers, the views and the reach of our videos, information about which countries and cities our visitors come from, as well as statistics about the gender ratios, age structures, providers, and interests of our visitors. Neither conclusions about individual users nor access to individual user profiles by the administrator are possible. **Data Transfer to third countries** Due to the affiliation of the provider Google Ireland Limited to the Google group, which has its headquarters in the USA, a data transfer to Google LLC and thus to all states in which Google has data centers cannot be excluded. To ensure an adequate level of data protection, Google Ireland Limited bases such data transfers on the standard contractual clauses of the European Commission. In this context, we would like to point out that you are using the service provided by Google Ireland Limited (YouTube) and all associated functions such as sharing and rating videos, participation in discussions on your own responsibility. Data that you have voluntarily provided on YouTube will be processed by Google (e.g. name and username, email address, telephone number) and may therefore also be transmitted to third countries. The transfer of personal data to the USA was judged by the ECJ to be fundamentally unsafe without further security measures, as it cannot be ruled out that US security authorities will gain access to this data. It is possible for you to restrict the processing of your data by Google. To do this, you can open the general settings of your Google account and change your privacy settings. Information on how to individualize your privacy settings can be found here: [https://policies.google.com/privacy?hl=de&gl=de#infochoices](https://policies.google.com/privacy?hl=de&gl=de#infochoices) You can also change certain settings for your mobile devices (e.g. smartphones, tablets, etc.) so that Google only has limited access to your contact data, location data, calendar data or photos, among other things. These setting options differ depending on the operating system used on your mobile device. *XING* We use our XING presence to provide information about our company, products and services, combined with the opportunity for users to interact with us in a targeted manner. We are processing personal data basing on Art. 6 (1) f GDPR. Our legitimate interest is, in particular, our business interest in sharing information with our users and being able to communicate with them. Before we publish pictures of people, we ask for your consent (legal basis: Art. 6 (1) a GDPR), or we make a written contractual agreement with your (legal basis: Art. 6 (1) b GDPR). In exceptional cases, we may publish pictures based on our legitimate interest for making information about our company available (legal basis: Art. 6 (1) f GDPR). We process personal data ourselves via our XING account, and at the same time data is processed by New Work SE. In the case of the comment function, the legal basis is consent in accordance with Art. 6 (1) GDPR. Your data is stored for the duration of the processing of your request. Usually, the data is forwarded to the designated channels outside of XING. The data is checked regularly in XING by our social media team and deleted when the purpose expires. When visiting our XING presence, XING collects personal data of the users by using cookies. This data collection by XING may also occur for visitors which are not logged in or registered to XING. Details of, which data is processed by New Work SE, and for what purposes it is used, can be found in XING’s data privacy policy: [https://privacy.xing.com/en/privacy-policy](https://privacy.xing.com/en/privacy-policy) Furthermore, you have the possibility to request information via the XING privacy form or the archive requests: [www.XING.com/settings/privacy/data/disclosure](https://www.XING.com/settings/privacy/data/disclosure) It is not excluded, however, that data from users will be processed on systems outside the European Union. XING is committed to comply with EU data protection standards. A data transfer to systems outside the EU only will take place if the requirements of Art. 44 et seqq. GDPR are complied with. You can find more about this at: [https://privacy.xing.com/en/privacy-policy/who-may-receive-information-about-you/third-countries](https://privacy.xing.com/en/privacy-policy/who-may-receive-information-about-you/third-countries) We receive anonymous statistics on the usage and use of the website based on our contract with New Work SE as well as legitimate interest of New Work SE. Following information will be provided: - Follower: Number of people following us - including increases and development over a defined time frame. - Range: Number of people who see a specific post and number of interactions on a specific post. This allows us to determine, for example, which content is better accepted by the community than others. - Advertising performance: That shows how many people were reached or interacted with a post or paid ad. We use these statistics, from which we cannot identify individual users, to constantly improve our online offering on XING and to better respond to the interests of our users. We cannot link the statistical data with the profile data of our users. You can choose the form in which targeted advertising is displayed to you via your XING settings. We receive personal data via XING if you communicate this to us actively via a personal message on XING (e.g., via a possible chat function). We use your data (e.g., first name, surname) to respond to your request in our customer service. Furthermore, we also receive personal data via XING if you use a form with pre-filled fields with data from your profile to submit the data to us and send the data to us actively by clicking on a button. In case you require to assert your rights towards XING, we shall pass your concern on to XING. For more information regarding your rights against XING to access and control your personal data, please visit: [https://privacy.xing.com/en/privacy-policy/what-rights-can-you-assert](https://privacy.xing.com/en/privacy-policy/what-rights-can-you-assert) *TikTok* TikTok is a service provided by TikTok Technology Limited, 10 Earlsfort Terrace, Dublin, D02 T380 Ireland **(“TikTok Ireland”)** and TikTok Information Technologies UK Limited **(“TikTok UK”)**. Both parties have signed a joint control agreement. The purpose of data processing on our TikTok-Account is to provide information about products, services, and news, combined with the possibility for users to interact with us in a targeted manner. The legal basis for the data processing is Art. 6 (1) f GDPR. Our legitimate interest is in particular our business interest to share information with the visitors of the TikTok-Account and to be able to communicate with them. Before we publish pictures of people, we ask for your consent (legal basis: Art. 6 (1) a GDPR) or make a written contractual agreement with you (legal basis: Art. 6 (1) b GDPR). In exceptional cases, we may publish pictures based on our legitimate interest for making information about our company available (legal basis: Art. 6 (1) f GDPR) in conjunction with § 23 (1) Nr. 3 Kunsturhebergesetz). Our TikTok site is not addressed to people under the age of 16. We ask that individuals under the age of 16 not provide any personal information to us. When we learn that we have collected personal information from anyone under 16, we will take steps to delete the information as soon as possible. If you find out that a user of our website is under the age of 16, please contact us via Alias. We will handle this information strictly confidential. **Use of TikTok for Business Insights** We use a business corporate account that allows us to create or place advertisements or sponsored content on websites operated by TikTok. This makes it possible for us to evaluate your interaction with our content on a statistical basis. The control of advertising for specific target groups is a legitimate interest of our company. The responsibility for data collection lies mainly with TikTok Technology Limited, (“TikTok Ireland”), and TikTok Information Technologies UK Limited (“TikTok UK”). Conflicting interests of users are not overriding (publication of individual target group optimized advertising). Our legal basis is Art. 6 (1) f GDPR. When you visit our TikTok website and its content, TikTok collects, among other things, automatically collected data such as your IP address as well as other information that is available in the form of cookies on your PC. Furthermore, TikTok stores information about the end devices of its users (e.g. advertising ID). If you are logged in as a user, a cookie with your TikTok ID is stored on your terminal device. This allows TikTok to track when you visited this page and how you used it. In addition, TikTok processes data that you have provided voluntarily (e.g. name and username, email address, phone number, contacts, and direct messages). You have the option to restrict the processing of your data by TikTok. For this purpose, you can open the general settings of your TikTok account and change the privacy settings. You can check and adjust your privacy settings here: [https://support.tiktok.com/en/account-and-privacy/account-privacy-settings](https://support.tiktok.com/en/account-and-privacy/account-privacy-settings) To contact TikTok, you can use this link: [https://www.tiktok.com/legal/page/global/impressum/en](https://www.tiktok.com/legal/page/global/impressum/en) The data collected about you in this context will be processed by TikTok Technology Limited and TikTok Information Technologies UK Limited and transferred to countries outside the European Union. TikTok bases this on the EU standard contractual clauses. Information about the data processing carried out by TikTok Technology Ltd. and the related purposes is available in the TikTok Technology Ltd. privacy policy. You can find this here: [https://www.tiktok.com/legal/page/eea/privacy-policy/en](https://www.tiktok.com/legal/page/eea/privacy-policy/en) In case of doubt, all companies in the TikTok Group have access to the stored data. If your rights need to be asserted against TikTok Technology Limited and TikTok Information Technologies UK Limited, we will forward your request to the responsible person. More information can be found here: [https://www.tiktok.com/legal/page/eea/privacy-policy/en](https://www.tiktok.com/legal/page/eea/privacy-policy/en) in “Your Rights and Choices”. Your personal data will be deleted by us if the purpose has expired. We have no influence on the storage by TikTok. Your data will be stored for the duration of the processing in the context of your visit to our TikTok site. If there are legal requirements, the data will be stored until the end of these regulations and then deleted. #### Data Processing in our Application Management You can use our career portal to apply for jobs advertised there or to submit unsolicited applications. Data processing takes place exclusively for the purpose of initiating employment relationships on the basis of Art. 88 (1) GDPR in conjunction with § 26 FDPA. Your data will be stored for the duration of the application process; if you enter into an employment relationship with us, your application data will be stored by us for the duration of your employment relationship. If, after completion of the application process, you are not accepted, we will retain your data on a legal basis for a further 6 months and then delete it; in the case of unsolicited applications or after your consent to store the data for a longer period for possible future employment, we will retain your data until you revoke it or for a maximum of two years. #### Data Processing in our Relationship with Customers and Third Parties We process personal data of you as prospective customer, customer, partner or third parties to establish, perform and terminate a contract pursuant to Art. 6 (1) b GDPR. Prior to a contract, your personal data can be processed to prepare bids or purchase orders or to fulfil other requests of the prospective customer relating to contract conclusion. In this regard, you will need to provide any personal data that we need for preparing and carrying out our business relationship with you. In the absence of this information, we will not be able to process your inquiry and/or to perform the contract. As prospective customers you can be contacted during the contract preparation process using the information that you have provided. We also process personal data for advertising purposes, if this is consistent with the contractual purpose pursuant Art. 6 (1) f GDPR. If your personal data is collected only for advertising purposes, you can choose whether to provide this data. You shall be informed that providing data for this purpose is voluntary. As part of the communication process, Kubermatic will ask for your consent. When giving consent, you will be given a choice among available forms of contact, such as e-mail and phone to withdraw your consent. If you object to the use of your data for advertising purposes, we will no longer use it for these purposes and will restrict or block from use for these purposes. Next to advertising purposes, the legitimate interests, which coincide with the particular purpose, include but are not limited to: Ensure the technical operation, responding to inquiries that are not related to the contract, ensure data security, ensure data availability, and rectification of errors and faults. In the event we need to disclose data for these purposes, we will expressly notify you of this circumstance. In the absence of this information, we may not be able to process your inquiry. We will also process your personal data for the purpose of compliance with statutory requirements that apply to us pursuant to Art. 6 (1) c GDPR. These requirements may exist under the trade, tax, money laundering, financial, or criminal code. The processing purposes are determined by the applicable statutory duty; generally, data processing will only serve the purpose of compliance with monitoring and disclosure duties under national law. *Recipients of Personal Data* We engage third party companies or individuals as service providers or business partners to support our business. These third parties are our processors and may, for example, provide and help us with computing and storage services. From time to time, we may remove or engage new processors. Kubermatic will ensure that processors are bound by written agreements that require them to provide an appropriate level of protection. Our service providers have been contractually obligated to maintain confidentiality and protect data in the event that access to personal data cannot be excluded. Data disclosure to legal authorities requires the existence of overriding statutory provisions. Data will only be transferred to third countries in compliance with the rights of the data subject and only if sufficient guarantees are effective pursuant to Art. 44 et seqq. GDPR, especially under the provisions of the EU Standard Contractual Clauses. *Deletion and Storage of Data* We will delete your personal data if it is no longer required for the purposes we pursue and if no other statutory provisions apply. *Third Party Information* We may use third-party sites and third-party platforms as well as publicly available information to collect and add some information to the information provided by you in order to give you relevant communication (for marketing purposes). Examples of collected information are additional work-related profile information. ### 5. Data Security Your personal data are protected from unauthorized access and unlawful processing or transfer, as well as from accidental loss, alteration or destruction. Before the introduction of new methods of data processing, particularly new IT systems, Kubermatic undertakes technical and organizational measures to protect your personal data. These measures are based on the state of the art, the risks of processing and the need to protect the data. The technical and organizational measures relevant to data protection are documented by Kubermatic and reviewed by the Data Protection Officer. Our security measures will be continuously improved based on the state of the art. ### 6. Rights of Data Subjects If your personal data is processed, you are a “data subject” within the meaning of the GDPR and you are entitled to the following claims against the “controller”: *Right of access* You have the right to obtain from us confirmation as to whether or not personal data concerning you is being processed. If we did process your personal data, you are entitled to further rights to access set forth in Art. 15 GDPR. *Right to rectification* If data that we collected on you is inaccurate or incomplete, you may claim the rectification without undue delay pursuant to Art. 16 GDPR. *Right to restriction of processing* Subject to Art. 18 GDPR, you may also have the right to claim the restriction of processing of personal data concerning you. Where processing has been restricted, your personal data shall only be processed with your consent or for the assertion, exercise or defense of legal claims or for the protection of the rights of another natural or legal person, or for reasons of important public interest of the Union or of a Member State. We will notify you before the restriction is lifted. *Right to erasure* If one or more of the grounds listed in Art. 17 (1) GDPR apply, you may claim the erasure of personal data concerning you without undue delay, unless there is an exception pursuant to Art. 17 (3) GDPR. *Right to notification* If you have asserted the right to rectification, erasure of personal data, or restriction of processing, we are obligated pursuant to Art. 19 GDPR to notify all recipients to whom personal data has been disclosed, unless this proves impossible or involves disproportionate effort. In addition, you have the right to be informed about who these recipients are. You may exercise your right to be informed of those recipients against the controller. *Right to data portability* Furthermore, pursuant to Art. 20 GDPR, you have the right to receive the personal data concerning you in machine readable format and to transmit this data to another controller without hindrance, provided, however, that the conditions enumerated in Art. 20 (1) a GDPR exist, or to demand to have the personal data transmitted directly from us another controller, where technically feasible and if this does not adversely affect the rights and freedoms of others. This right shall not apply to processing of personal data necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller. *Right to object* You have the right to object at any time to the processing of personal data concerning you by written notice to Kubermatic which is based on Art. 6 (1) f GDPR. We shall not longer process your personal data unless we can demonstrate compelling legitimate grounds for the processing which override your interests, rights and freedoms or if the processing serves the assertion, exercise or defense of legal claims. *Right to withdraw the consent under data protection law, rules, and regulations* You may withdraw your data protection consent at any time by notifying Kubermatic. The withdrawal of consent shall not affect the lawfulness of processing based on this consent before its withdrawal. *Right to lodge complaints with the supervisory authority* If you have any objections or complaints with the way in which we process your personal data, you have the right to lodge a complaint with the relevant data protection supervisory authority, where the applicable laws provide for such remedy. *How to contact us or to exercise your rights* If you should have any questions on the processing of your personal data, your rights as a data subject, or any consent that may have been granted, you may contact us free of charge. If you wish to exercise any or all of your rights, please email us at [privacy@kubermatic.com](mailto:privacy@kubermatic.com) or write a letter to the address set forth in section 1 above. ### 7. Provision obligation Without providing correct data, the conclusion of a contract may not be possible. The result may be that services cannot be provided or cannot be provided in time. ### 8. Changes to Privacy Policy Since Kubermatic may change and complement data processing processes, it may become necessary to amend this Privacy Policy in individual cases. Kubermatic provides the effective Version of this Privacy Policy at any time on [https://www.kubermatic.com/privacy/](https://www.kubermatic.com/privacy/). Status: 30.09.2024 --- ## Kubermatic Community Engagement - **URL:** https://www.kubermatic.com/company/community/ - **Date:** 2026-04-30 - **Description:** Join the Kubermatic open source community — explore projects, meet maintainers, and learn Platform Engineering Community First # Scale Your Expertise. Build the Future of Platforms. Join a global community of Platform Engineers and SREs. Whether you're automating Day 2 operations or building the next generation of IDPs, this is your home base. [Join Our Slack](https://join.slack.com/t/kubermatic-community/shared_invite/zt-1jtex2o9f-fpaDZ2ytX7FmDaNOHqljIg) [Explore Kubermatic Learn](/learn/) ![Members of the Kubermatic team](/static/community-hero-team.jpg) Proud Member Of [![The Linux Foundation](/static/linux-foundation.svg)](https://www.linuxfoundation.org/ "The Linux Foundation") [![Cloud Native Computing Foundation](/static/cncf-stacked-color.svg)](https://www.cncf.io/ "Cloud Native Computing Foundation") [![Open Industry 4.0 Alliance](/static/openindustry4.svg)](https://openindustry4.com/ "Open Industry 4.0 Alliance") [![LF Networking](/static/lf-networking.png)](https://lfnetworking.org/ "LF Networking") [![EuroCloud Native](/static/eurocloudnative.svg)](https://www.eurocloudnative.de/ "EuroCloud Native") [![eco](/static/eco.svg)](https://international.eco.de/ "eco") [![Margo](/static/margo.svg)](https://margo.org/ "Margo") [![NeoNephos](/static/neonephos.svg)](https://neonephos.org/ "NeoNephos") [![Agentic AI Foundation](/static/aaif.svg)](https://aaif.io/ "Agentic AI Foundation") []() Kubermatic Labs ## Built in Our Labs. Open to All. We create and maintain critical infrastructure tools that power modern platforms. Explore our homegrown open source projects. ![Kubermatic Kubernetes Platform logo](/static/kubermatic-kubernetes-platform.svg) ### [Kubermatic Kubernetes Platform](https://github.com/kubermatic/kubermatic) The multi-cluster, multi-cloud Kubernetes management platform for automated ops at scale. [![Kubermatic Kubernetes Platform star count](https://img.shields.io/github/stars/kubermatic/kubermatic?style=social)](https://github.com/kubermatic/kubermatic/stargazers) ![KubeOne logo](/static/kubermatic-kubeone.svg) ### [KubeOne](https://github.com/kubermatic/kubeone) Automate full K8s cluster lifecycle management on any infrastructure. [![KubeOne star count](https://img.shields.io/github/stars/kubermatic/kubeone?style=social)](https://github.com/kubermatic/kubeone/stargazers) ![KubeLB logo](/static/kubermatic-kubelb.svg) ### [KubeLB](https://github.com/kubermatic/kubelb) The Kubernetes-native Load Balancer for edge and bare metal. [![KubeLB star count](https://img.shields.io/github/stars/kubermatic/kubelb?style=social)](https://github.com/kubermatic/kubelb/stargazers) ![machine-controller logo](/static/kubermatic-machine-controller.svg) ### [machine-controller](https://github.com/kubermatic/machine-controller) Cluster API implementation for managing worker nodes. [![machine-controller star count](https://img.shields.io/github/stars/kubermatic/machine-controller?style=social)](https://github.com/kubermatic/machine-controller/stargazers) Upstream First ## We Don't Just Use the Stack. We Build It. Kubermatic is a consistent Top 5 Corporate Contributor to Kubernetes, and our engineers ship code, reviews, and designs across the cloud-native stack — from networking and virtualization to observability and bare-metal provisioning. [![Kubernetes](/images/logos/kubernetes-logo.svg) \ **Kubernetes** \ Core Contributor](https://kubernetes.io) [![Cluster API](/static/cluster-api-logo.svg) \ **Cluster API** \ Lifecycle Automation](https://cluster-api.sigs.k8s.io) [![KubeVirt](/static/kubevirt-square.svg) \ **KubeVirt** \ Virtualization](https://kubevirt.io) [![kcp](/static/kcp-icon-color.png) \ **kcp** \ Orchestration](https://kcp.io) [![Prometheus](/static/prometheus-icon-color.png) \ **Prometheus** \ Observability](https://prometheus.io) [![Cilium](/static/cilium-square.svg) \ **Cilium** \ Networking](https://cilium.io) [![Istio](/static/istio.svg) \ **Istio** \ Service Mesh](https://istio.io) [![Envoy](/static/envoy.svg) \ **Envoy** \ Edge Proxy](https://www.envoyproxy.io) [![Helm](/static/helm.svg) \ **Helm** \ Package Management](https://helm.sh) [![KubeOVN](/static/kube-ovn-square.svg) \ **KubeOVN** \ Cloud Native Networking](https://www.kube-ovn.io) [![Tinkerbell](/static/tinkerbell.svg) \ **Tinkerbell** \ Bare Metal Provisioning](https://tinkerbell.org) [![Flatcar](/static/flatcar-logo.svg) \ **Flatcar** \ Container Linux](https://www.flatcar.org) ## Built by Engineers, for Engineers Our team doesn't just support the community; we are part of it. Meet the people maintaining the projects you rely on. ![Sebastian Scheele](/static/authors/Sebastian-Scheele.png) Sebastian Scheele CNCF Governing Board LF Networking Board Member kcp Maintainer Co-founder and CEO, shaping the future of control planes with kcp. [](https://twitter.com/sscheele)[](https://github.com/scheeles) ![Mario Fahlandt](/static/authors/mario-fahlandt.jpg) Mario Fahlandt CNCF TOC Member SIG ContribEx TAG Operational Resilience Customer Delivery Architect. Active in Kubernetes SIG ContribEx and CNCF TAG Operational Resilience. ![Christoph Mewes](/static/authors/christoph-mewes.jpeg) Christoph Mewes kcp Maintainer Senior Software Engineer contributing to kcp. ![Marko Mudrinić](/static/authors/marko-mudrinic.jpg) Marko Mudrinić kcp Maintainer Senior Software Engineer contributing to kcp. [](https://twitter.com/xmudrii)[](https://github.com/xmudrii) ![Simon Bein](/static/authors/simon-bein.jpeg) Simon Bein kcp Maintainer Software Engineer contributing to kcp. [](https://github.com/SimonTheLeg) ![Karol Szwaj](/static/authors/karol-szwaj.jpg) Karol Szwaj kcp Maintainer Software Engineer contributing to kcp. ## Kubermatic Learn Practical, hands-on learning paths for the modern Platform Engineer. [View all tutorials →](/learn/) [**Zero to Production: KubeOne on Bare Metal** \ Master KubeOne to provision, manage, and repair Kubernetesclusters. \ Intermediate 45 mins](/learn/kubeone/kubeone-baremetal/) [**Installing Kubermatic Virtualization with the Declarative Installer** \ Kubermatic Virtualization is a stack of well-known open-source components plus Kubermatic's own controllers and UI. \ Beginner 30 mins](/learn/kubermatic-virtualization/installing-kubermatic-virtualization/) [**kcp Workspaces vs Namespaces vs vcluster** \ Understand the difference and usecases of kcp, namespaces and vCluster. \ Intermediate 30 mins](/learn/kcp/workspaces-vs-namespaces-vs-vcluster/) CNCF Sandbox Project ## kcp: The Control Plane for Platforms We believe the future of Platform Engineering isn’t just more clusters—it’s better control planes. As active contributors to the [**kcp**](https://kcp.io) project, the foundation of the [Kubermatic Developer Platform (KDP)](/products/kubermatic-developer-platform/), we are helping build the primitives for massive multi-tenancy and API service delivery. [View Project on GitHub](https://github.com/kcp-dev/kcp) [#kcp-dev on Slack](https://kubernetes.slack.com/archives/C09C7UP1VLM) ``` apiVersion: apis.kcp.io/v1alpha1 kind: APIExport metadata: name: database-service spec: # Provide your API to 1000s of tenants latestResourceSchemas: - v1.database.acme.io ``` []()[]() ## Upcoming Events 08 Jul ![Proud partner of WeAreDevelopers World Congress Europe, 8-10 July, Berlin](/static/event-wearedevelopers26_hu_37fc24874fa9e0a5.jpg) Onsite Conference Berlin, Germany ## [Join us in Berlin at WeAreDevelopers](https://www.wearedevelopers.com/) [Join Here](https://www.wearedevelopers.com/) 02 Sep ![](/static/containerdays-hamburg-2026_hu_6b9f10471eb809c9.jpg) Onsite Conference Hamburg, Germany ## [ContainerDays Hamburg is Back in the Harbor of Hamburg for 2026!](https://www.containerdays.io/containerdays-hamburg-2026/) [Join Here](https://www.containerdays.io/containerdays-hamburg-2026/) September Mon Tue Wed Thu Fri Sat Sun 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 ## Where to Find Us ### kcp Community Meetings The kcp community meets every second Thursday at 11:00 AM EST / 17:00 CET. Everyone is welcome. Every second Thursday 11:00 AM EST · 17:00 CET [**Meeting Agenda** \ Running notes and upcoming topics](https://docs.google.com/document/d/1PrEhbmq1WfxFv1fTikDBZzXEIJkUWVHdqDFxaY1Ply4) [**CNCF Community Page** \ RSVP to the next meeting](https://community.cncf.io/kcp/) [**Recordings** \ Watch past sessions on YouTube](https://www.youtube.com/channel/UCfP_yS5uYix0ppSbm2ltS5Q) ### Community Outposts We meet you where you are. Engage with our team on your favorite platforms. [**Reddit** \ r/kubermatic](https://www.reddit.com/r/kubermatic/) [**Community Slack** \ kubermatic-community.slack.com](https://join.slack.com/t/kubermatic-community/shared_invite/zt-1jtex2o9f-fpaDZ2ytX7FmDaNOHqljIg) [**YouTube** \ Talks, demos, and tutorials](https://www.youtube.com/channel/UCHyOXqpOR7TRyOzS5bolcUw) [**LinkedIn** \ Company updates and announcements](https://www.linkedin.com/company/kubermatic/) [d \ **Daily.dev** \ Engineering Squad](#) ## The Control Plane Newsletter The Control Plane is a monthly newsletter for Platform Engineers, SREs, and infrastructure leaders who run Kubernetes in production. Each issue features a well-researched deep dive into a topic that matters at scale — sovereignty, GPU orchestration, multi-cluster operations — backed by real architecture patterns, policy examples, and data you can act on. You'll also get curated industry signals, Kubermatic product updates, war stories from the field, and community events worth your time. One email. Once a month. No fluff. ### Subscribe ## Community Requests Whether you are interested in our community activities, want to collaborate with us or have any suggestions, please let us know. We would love to connect with you! --- ## Contact Us - **URL:** https://www.kubermatic.com/contact-us/ - **Date:** 2025-11-04 - **Description:** We are happy to connect! Reach out to us for general questions, careers, and any other topic on your mind. # Contact Us We are happy to connect! Reach out to us for general questions, careers, and any other topic on your mind. For sales and pricing related topics, please reach out via: [Contact Sales](/contact-sales/) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ## Ask Us Anything If our form couldn't load correctly – This can have multiple reasons like ad blocker, not accepted cookies, JavaScript deactivated. However, you can still get in touch with us! Simply click on the button below, and you'll be able to submit the form and reach out to us for any inquiries or assistance you need. [Open form](https://share.hsforms.com/1bhk4slbnSdiZmDYnByBIaA2piu8) - [![github](/images/icons/github-gold-grad.svg) github.com/kubermatic](https://github.com/kubermatic/) - [![slack](/images/icons/slack-gold-grad.svg) kubermatic-community.slack.com](https://join.slack.com/t/kubermatic-community/shared_invite/zt-1jtex2o9f-fpaDZ2ytX7FmDaNOHqljIg) - [![twitter](/images/icons/x-gold-grad.svg) @kubermatic](https://twitter.com/Kubermatic) - [![linkedin](/images/icons/linkedin-gold-grad.svg) linkedin.com/company/kubermatic](https://www.linkedin.com/company/kubermatic) ## Our Office ### Hamburg Willy-Brandt Straße 23 20457 Hamburg --- ## Get Kubermatic Kubernetes Platform Demo - **URL:** https://www.kubermatic.com/demo/ - **Date:** 2024-11-25 - **Description:** Request your Kubermatic Kubernetes Platform demo to start your multicloud journey today. # Get started with your multicloud journey today Discover how our expert solutions can modernize your IT infrastructure and scale your business. Request a demo now and: - Speed up cloud native adoption - Automate developer experience and Day2 operations - Don't compromise on your enterprise standards ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) If our widget couldn't load correctly – This can have multiple reasons like ad blocker, not accepted cookies, JavaScript deactivated. However, you can still get in touch with us! Simply click on the button below, and you'll be able to submit your request and reach out to us for any inquiries or assistance you need. [Open widget](https://meetings.hubspot.com/bogdan/inbound-shared-meeting-invite) ## Leading Companies Trust In Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) --- ## Press - **URL:** https://www.kubermatic.com/company/press/ - **Date:** 2026-07-08 - **Description:** Check all the latest news and updates about our company and the Kubermatic Kubernetes Platform. Here’s what different news, journals and magazines are saying about us. # Press Microservices and containers are a thrilling topic. Here’s some of the latest buzz about us. [Media Kit](https://drive.google.com/drive/folders/1o2Y18LLcwzChL_r5Hk3F6Fvq1k85er7l?usp=sharing) ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ![PR Newswire by Cision logo](/static/prnewswire-by-cision.svg) ### [Kubermatic positioned as a Leader in the SPARK Matrix™: Edge Kubernetes Platforms, Q3 2026, by QKS Group](https://www.prnewswire.com/news-releases/kubermatic-positioned-as-a-leader-in-the-spark-matrix-edge-kubernetes-platforms-q3-2026-by-qks-group-302820491.html) July 8, 2026 via PR Newswire by Cision ![QKS Group logo](/static/qks-group.svg) ### [Kubermatic positioned as a Leader in the SPARK Matrix™: Edge Kubernetes Platforms, Q3 2026, by QKS Group](https://qksgroup.com/newsroom/kubermatic-positioned-as-a-leader-in-the-spark-matrix-edge-kubernetes-platforms-q3-2026-by-qks-group-1720) July 7, 2026 via QKS Group ![ChannelPartner logo](/static/channelpartner.svg) ### [Anthropic-Abschaltung als längst überfälliger Weckruf](https://www.channelpartner.de/article/4186160/anthropic-abschaltung-als-langst-uberfalliger-weckruf.html) June 18, 2026 via ChannelPartner ### [Souveränität: KI-Verfügbarkeit unter eigener Kontrolle](https://ap-verlag.de/souveraenitaet-ki-verfuegbarkeit-unter-eigener-kontrolle/105387/) June 17, 2026 via ap-verlag ### [Nach VMware-CSP-Ausstieg – Cloud Service Provider suchen souveräne Alternativen](https://ap-verlag.de/nach-vmware-csp-ausstieg-cloud-service-provider-suchen-souveraene-alternativen/105302/) June 16, 2026 via ap-verlag ![IT Daily logo](/static/it-daily-logo.png) ### [Nach VMware-CSP-Ausstieg – Cloud Service Provider suchen souveräne Alternativen](https://www.it-daily.net/it-management/cloud-computing/vmware-ausstieg-souveraene-alternativen) June 15, 2026 via IT Daily ![line-of.biz logo](/static/lineofbiz.jpg) ### [Getrennte Infrastrukturwelten sind teurer – langfristig lohnt sich Konvergenz](https://line-of.biz/cloud-computing/getrennte-infrastrukturwelten-sind-teurer-langfristig-lohnt-sich-konvergenz/) June 8, 2026 via line-of.biz ![IT Daily logo](/static/it-daily-logo.png) ### [VMware-Migration auf dem Prüfstand: Konvergenz lohnt sich langfristig](https://www.it-daily.net/it-management/business-software/vmware-migration-pruefstand) June 2, 2026 via IT Daily ![Security Insider logo](/static/security-insider-logo.svg) ### [Swisscom veröffentlicht komplette souveräne Cloud-Infrastruktur](https://www.security-insider.de/swisscom-kubernetes-architektur-souveraene-private-cloud-a-b1d80e4d46847571294872bf9b2ea1e9/) June 1, 2026 via Security Insider ![SoftwareKing24 logo](/static/softwareking24.png) ### [KubeLB 1.4: Neues Dashboard und Air-Gap-Support](https://softwareking24.com/it-news/kubelb-1-4-neues-dashboard-und-air-gap-support/) May 30, 2026 via SoftwareKing24 ![IP Insider logo](/static/ip-insider.svg) ### [KubeLB 1.4 bringt Web-Dashboard und Air-Gap-Support](https://www.ip-insider.de/kubelb-14-bringt-web-dashboard-und-air-gap-support-a-97470cb6ff55fd2a2f4d3dcac6fb5053/) May 29, 2026 via IP Insider ![IT Daily logo](/static/it-daily-logo.png) ### [Kubermatic und Dell Technologies geben strategische Partnerschaft bekannt](https://www.it-daily.net/shortnews/kubermatic-dell-technologies-partnerschaft) May 19, 2026 via IT Daily ![Connect Professional logo](/static/connect-professional.svg) ### [Kubermatic und Dell vereinbaren strategische Partnerschaft](https://www.connect-professional.de/netzwerke-it-infrastruktur/kubermatic-dell-strategische-partnerschaft-it-infrastruktur-404791.html) May 19, 2026 via Connect Professional ![B2B Cyber Security logo](/static/b2b-cyber-security-logo.png) ### [Ein blinder Fleck in der Cyberresilienz](https://b2b-cyber-security.de/ein-blinder-fleck-in-der-cyberresilienz/) May 16, 2026 via B2B Cyber Security ![A-und-D-Magazin logo](/static/industr.svg) ### [Darum bleibt die "souveräne KI" in der EU vorerst ein Wunschtraum](https://www.industr.com/de/darum-bleibt-die-souveraene-ki-in-der-eu-vorerst-ein-wunschtraum-2913017) May 13, 2026 via A-und-D-Magazin ![Cloudcomputing Insider logo](/static/logo-1-.svg) ### [Swisscom Kubernetes-Architektur: Souveräne private Cloud](https://www.cloudcomputing-insider.de/swisscom-kubernetes-architektur-souveraene-private-cloud-a-aa42d114daf75964534ccc785eb08722/) May 11, 2026 via Cloudcomputing Insider ![Heise logo](/static/heise-online-logo.svg) ### [Developer-Häppchen fürs Wochenende: kleinere News der Woche](https://www.heise.de/news/Developer-Haeppchen-fuers-Wochenende-kleinere-News-der-Woche-11281545.html) May 9, 2026 via Heise ### [Das vergessene Fundament der KI-Transformation](https://www.computingdeutschland.de/podcast/2026/das-vergessene-fundament-der-ki-transformation) May 5, 2026 via Computing Deutschland ![Computer & Automation logo](/static/computer-automation.svg) ### [Kubernetes and Cloud Native in der Fabrik](https://epaper.computer-automation.de/frontend/mvc/catalog/by-name/CUA?catalogName=CUA2605D) May 1, 2026 via Computer & Automation ![Heise logo](/static/heise-online-logo.svg) ### [CloudLand 2026: Last Call zum Cloud-Native-Festival](https://www.heise.de/news/CloudLand-2026-Last-Call-zum-Cloud-Native-Festival-11267514.html) April 25, 2026 via Heise ![Computer & Automation logo](/static/computer-automation.svg) ### [Container und Kubernetes – die Basics](https://www.computer-automation.de/engineering/kubermatic--container-und-kubernetes---die-basics.htm) April 23, 2026 via Computer & Automation ![Security Insider logo](/static/security-insider-logo.svg) ### [Fail-safe operation for cloud regions Digital sovereignty also for backups and emergency plans](https://www.security-insider.de/digitale-souveraenitaet-auch-fuer-backups-und-notfallplaene-a-f94074dc884c0c97444fc906f555deb0/) April 13, 2026 via Security Insider ![Cloud Experts Network logo](/static/cloudexperts.png) ### [Swisscom's Journey from Vendor Lock-In to Cloud Native Infrastructure Platform](https://telcofutures.net/swisscoms-journey-cloud-native-platform/) April 8, 2026 via Cloud Experts Network ![netzwoche logo](/static/netzwoche.svg) ### [Swisscom launches Kubernetes service as part of its private cloud](https://www.netzwoche.ch/news/2026-04-08/swisscom-lanciert-kubernetes-service-als-teil-ihrer-private-cloud) April 8, 2026 via netzwoche ![ITMagazine logo](/static/itmagazine.png) ### [Swisscom launches sovereign Kubernetes service](https://www.itmagazine.ch/artikel/86906/Swisscom_bringt_souveraenen_Kubernetes_Service.html) April 7, 2026 via ITMagazine ![ComputerWeekly.de logo](/static/computerweekly-logo.jpg) ### [KubeCon + CloudNativeCon Europe 2026: KI, Souveränität](https://www.computerweekly.com/de/news/366641101/KubeCon-CloudNativeCon-Europe-2026-KI-Souveraenitaet) April 3, 2026 via ComputerWeekly.de ![Heise logo](/static/heise-online-logo.svg) ### [Wie funktioniert eigentlich ein Open-Source-Projekt – ein Blick in Kubernetes](https://www.heise.de/hintergrund/Wie-funktioniert-eigentlich-ein-Open-Source-Projekt-ein-Blick-in-Kubernetes-11227313.html) April 2, 2026 via Heise ![Storage Insider logo](/static/storage-insider.svg) ### [Digitale Souveränität auch für Backups und Notfallpläne](https://www.storage-insider.de/digitale-souveraenitaet-auch-fuer-backups-und-notfallplaene-a-b903f7616bd94c70b0030dd2f00e5cc9/) March 31, 2026 via Storage Insider ![Security Boulevard logo](/static/security-boulevard.jpeg) ### [Let's Stop Sovereignty Washing](https://securityboulevard.com/2026/03/lets-stop-sovereignty-washing/) March 31, 2026 via Security Boulevard ![CNCF Architecture logo](/static/CNCF-logo.png) ### [A modern and sovereign Private Cloud Kubernetes Service for Swiss-based enterprises](https://architecture.cncf.io/architectures/swisscom-kubernetes-service/) March 25, 2026 via CNCF Architecture ![Heise logo](/static/heise-online-logo.svg) ### [Kubermatic SecureGuard: Automatisiertes Secrets-Management für Kubernetes](https://www.heise.de/news/Kubermatic-SecureGuard-Automatisiertes-Secrets-Management-fuer-Kubernetes-11222517.html) March 24, 2026 via Heise ![Safety Security logo](/static/Safety_Security_Logo_Final-01_RGB.png) ### [Sovereign emergency plans – a blind spot in cyber resilience](https://www.safety-security.ch/notfallplaene-cyberresilienz/) March 19, 2026 via Safety Security ![Infopoint logo](/static/infopoint-security-logo.svg) ### [Souveräne Notfallpläne: Der blinde Fleck der Cyberresilienz](https://www.infopoint-security.de/souveraene-notfallplaene-der-blinde-fleck-der-cyberresilienz/a44082/) March 11, 2026 via Infopoint ![nt4 Admins logo](/static/nt4-admins.png) ### [Hardware failures are becoming a challenge in AI operations](https://nt4admins.de/virtualisierung/hardwareausfaelle-werden-zur-herausforderung-im-ki-betrieb/) March 6, 2026 via nt4 Admins ![Industrie Anzeiger logo](/static/industrieanzeiger.png) ### [Wie die Open Industry 4.0 Alliance Automatisierung von Hardware löst](https://industrieanzeiger.industrie.de/management/it/wie-die-open-industry-4-0-alliance-automatisierung-von-hardware-loest/) February 11, 2026 via Industrie Anzeiger ![it-nerd24 logo](/static/it-nerd24-2026.svg) ### [Top Products 2026: Which Software Companies Really Need Now](https://it-nerd24.de/tech-blog/top-produkte-2026-welche-software-wird-am-meisten-nachgefragt) January 13, 2026 via it-nerd24 ![Data Center Insider logo](/static/datacenter-insider.svg) ### [Weltbaum-Update für Kubernetes](https://www.datacenter-insider.de/weltbaum-update-fuer-kubernetes-a-f0a6828449b16e8932439ec6a7c69267) January 11, 2026 via Data Center Insider ![Heise logo](/static/heise-online-logo.svg) ### [Linux Foundation übernimmt KI-Projekte MCP und AGENTS.md](https://www.heise.de/select/ix/2026/2/2533213251002502195) January 10, 2026 via Heise ![nt4 Admins logo](/static/nt4-admins.png) ### [Trends im Container-Management in 2026](https://nt4admins.de/verwaltungs-tools/trends-im-container-management-in-2026/) January 8, 2026 via nt4 Admins ![Data Center Insider logo](/static/datacenter-insider.svg) ### [VMware-Alternative mit Kubernetes Kubermatic veröffentlicht Cloud-native Virtualisierungsplattform](https://www.datacenter-insider.de/kubermatic-veroeffentlicht-cloud-native-virtualisierungsplattform-a-a6270b6d2723ed2e8c4204e1979c3f81/) January 7, 2026 via Data Center Insider ![Data Center Insider logo](/static/datacenter-insider.svg) ### [Linux-Stiftung gründet Agentic AI Foundation](https://www.datacenter-insider.de/linux-stiftung-gruendet-agentic-ai-foundation-a-3fb66d25802cf41b6b481665eb877496/) January 1, 2026 via Data Center Insider ### [Die Glorreichen Sieben: Trends im Bereich Container-Management für 2026](https://ap-verlag.de/die-glorreichen-sieben-trends-im-bereich-container-management-fuer-2026/101481/) December 29, 2025 via ap-verlag ![IT Daily logo](/static/it-daily-logo.png) ### [Container-Management für 2026 Die Glorreichen Sieben der Container-Ära](https://www.it-daily.net/it-management/data-center/glorreichen-sieben-container-aera) December 28, 2025 via IT Daily ![Data Center Insider logo](/static/datacenter-insider.svg) ### [MCP, Goose und Agents.md werden gemeinnützig betreut Linux-Stiftung gründet Agentic AI Foundation](https://www.datacenter-insider.de/linux-stiftung-gruendet-agentic-ai-foundation-a-3fb66d25802cf41b6b481665eb877496/) December 13, 2025 via Data Center Insider ![mit-blog.de logo](/static/mit-blog.png) ### [Künstliche Intelligenz auf Kubernetes – Kubermatic jetzt offiziell Kubernetes AI-konform](https://mit-blog.de/kuenstliche-intelligenz-auf-kubernetes-kubermatic-jetzt-offiziell-kubernetes-ai-konform/) December 12, 2025 via mit-blog.de ![Linux-Magazin logo](/static/linux-magazin-logo.png) ### [Kubermatic Virtualization in stabiler Version 1.0](https://www.linux-magazin.de/news/kubermatic-virtualization-in-stabiler-version-1-0/) December 11, 2025 via Linux-Magazin ![Heise logo](/static/heise-online-logo.svg) ### [Anthropic trennt sich von MCP und schenkt es der Linux Foundation](https://www.heise.de/news/Anthropic-trennt-sich-von-MCP-und-schenkt-es-der-Linux-Foundation-11109827.html) December 10, 2025 via Heise ![Heise logo](/static/heise-online-logo.svg) ### [Analyse: Projektsterben in der Cloud-Native-Welt](https://www.heise.de/hintergrund/Analyse-Projektsterben-in-der-Cloud-Native-Welt-11107110.html) December 8, 2025 via Heise ![IT Daily logo](/static/it-daily-logo.png) ### [Confidential Containers – Leitfaden für Plattformingenieure](https://www.it-daily.net/it-management/business-software/confidential-containers-plattformingenieure) November 24, 2025 via IT Daily ![Heise logo](/static/heise-online-logo.svg) ### [CNCF standardisiert KI-Infrastruktur mit neuem Kubernetes-Programm](https://www.heise.de/news/CNCF-standardisiert-KI-Infrastruktur-mit-neuem-Kubernetes-Programm-11074337.html) November 13, 2025 via Heise ![computerwoche.de logo](/static/computerwoche.svg) ### [IT-Produkte der Woche](https://www.computerwoche.de/article/3556601/it-produkte-der-woche.html) October 31, 2025 via computerwoche.de ### [Kubermatic KKP 2.29](https://security-storage-und-channel-germany.de/kubermatic-kkp-2-29/) October 29, 2025 via Security Storage und Channel Germany ![Storage Consortium logo](/static/storageconsortium.png) ### [Kubermatic KubeLB 1.2 Update: KI-Gateway und Bare-Metal-CLI für Cloud-native Infrastrukturen verfügbar](https://storageconsortium.de/kubermatic-kubelb-12-update-ki-gateway-und-bare-metal-cli-f%C3%BCr-cloud-native-infrastrukturen-verf%C3%BCgbar) October 16, 2025 via Storage Consortium ![Silicon Technology logo](/static/silicon.png) ### [Von VMware zu Kubernetes](https://www.silicon.de/41721293/von-vmware-zu-kubernetes) September 17, 2025 via Silicon Technology ![ITWELT logo](/static/itwelt-logo.png) ### [Von VMware zu Kubernetes: Tools und Praxistipps für die große Migration](https://itwelt.at/news/von-vmware-zu-kubernetes-tools-und-praxistipps-fuer-die-grosse-migration/) September 17, 2025 via ITWELT ![Dealers-Only logo](/static/dealers-only.png) ### [Kubermatic und Bechtle AV Software Solutions 360° geben Partnerschaft bekannt](https://dealers-only.de/wp-content/uploads/DEALERS-ONLY-1825.pdf) September 3, 2025 via Dealers-Only ![CRN logo](/static/crn-de.png) ### [Native Cloud-Anwendungen: Kubermatic und Bechtle präsentieren sich als Alternative zu US-Riesen](https://www.crn.de/news/2025/kubermatic-und-bechtle-schlie-en-partnerschaft-fur-cloud-anwendungsplattformen) August 19, 2025 via CRN ![IT-business logo](/static/it-business.svg) ### [Kubermatic und Bechtle AV Software Solutions 360° kooperieren](https://www.it-business.de/kubermatic-und-bechtle-av-software-solutions-360-kooperieren-a-80bbbefdc8e3f3563c8b0371ea91cae9/) August 18, 2025 via IT-business ![Storage Insider logo](/static/storage-insider.svg) ### [VMware-Migration in fünf Schritten](https://www.storage-insider.de/vmware-migration-in-fuenf-schritten-a-618e880c2e76114ada14b1710609ad9e/) July 31, 2025 via Storage Insider ![IP Insider logo](/static/ip-insider.svg) ### [VMware-Migration in fünf Schritten](https://www.ip-insider.de/vmware-migration-in-fuenf-schritten-a-5ed1543d62bd33efdffced7c177d4e99/) July 21, 2025 via IP Insider ![Data Center Insider logo](/static/datacenter-insider.svg) ### [Strategische Auswege für CIOs: VMware-Migration in fünf Schritten](https://www.datacenter-insider.de/vmware-migration-in-fuenf-schritten-a-047358334817cf3279e4b376d0bf0965/) July 21, 2025 via Data Center Insider ![Heise logo](/static/heise-online-logo.svg) ### [Developer Snapshots: Kleinere News der Woche](https://www.heise.de/news/Developer-Snapshots-Kleinere-News-der-Woche-10492169.html) July 18, 2025 via Heise ![Cloudcomputing Insider logo](/static/logo-1-.svg) ### [VMware-Migration in fünf Schritten](https://www.cloudcomputing-insider.de/vmware-migration-in-fuenf-schritten-a-2f42a810bd6950e6c83babb2b2899570/) July 18, 2025 via Cloudcomputing Insider ![computer & automation logo](/static/computer-automation.svg) ### [Kubermatic und Flecs vereinfachen App-Management](https://www.computer-automation.de/produktionssoftware/kubermatic-und-flecs-vereinfachen-app-management-in-der-industrie.htm) July 15, 2025 via computer & automation ![line-of.biz logo](/static/lineofbiz.jpg) ### [VMware-Migration reduziert Kosten](https://line-of.biz/it-infrastruktur-und-rechenzentren/vmware-migration-reduziert-kosten/) July 11, 2025 via line-of.biz ![IT Daily logo](/static/it-daily-logo.png) ### [VMware-Migration in fünf Schritten](https://www.it-daily.net/it-management/business-software/auswege-uebernahme-vmware-broadcom) July 10, 2025 via IT Daily ![CRN logo](/static/crn-de.png) ### [Digital Innovator Award für Kubermatic](https://www.crn.de/news/2025/digital-innovator-award-fur-kubermatic) July 2, 2025 via CRN ![CIO logo](/static/cio.svg) ### [Pharma-Forschungsprojekt Melloddy ermöglicht föderiertes Lernen](https://www.cio.de/article/4008806/pharma-forschungsprojekt-melloddy-ermoglicht-foderiertes-lernen.html) July 2, 2025 via CIO ![IT Administrator logo](/static/it-administrator-logo.svg) ### [Interview »Organisationen gewinnen Agilität«](https://www.it-administrator.de/heftarchiv-article?xv_article=ADMIN_2025_07_010&issue=072025&toc=2025-07) July 2, 2025 via IT Administrator ![IT Daily logo](/static/it-daily-logo.png) ### [Warum Platform Engineering unverzichtbar ist – und wo DevOps versagt hat](https://www.it-daily.net/it-management/business-software/platform-engineering-unverzichtbar) June 27, 2025 via IT Daily ![ITWELT logo](/static/itwelt-logo.png) ### [Warum Platform Engineering unverzichtbar ist – und wo DevOps versagt hat](https://itwelt.at/news/kommentar/warum-platform-engineering-unverzichtbar-ist-und-wo-devops-versagt-hat/) June 24, 2025 via ITWELT ![Intellyx logo](/static/intellyx.png) ### [Kubermatic Wins 2025 Digital Innovator Award from Intellyx](https://intellyx.com/2025/06/11/kubermatic-wins-2025-digital-innovator-award-from-intellyx/) June 10, 2025 via Intellyx ![Pressebox logo](/static/pressebox.svg) ### [AOE Group und Kubermatic schließen strategische Partnerschaft für Cloud-Native-Plattformen](https://www.pressebox.de/pressemitteilung/aoe-gmbh/AOE-Group-und-Kubermatic-schlieen-strategische-Partnerschaft-fr-Cloud-Native-Plattformen/boxid/1252513) June 6, 2025 via Pressebox ### [Kann sich Europa überhaupt von den US-Cloud-Giganten trennen?](https://ap-verlag.de/kann-sich-europa-ueberhaupt-von-den-us-cloud-giganten-trennen/96198/) May 29, 2025 via ap-verlag ![ZDNet logo](/static/zdnet.svg) ### [Trennt sich Europa von den US-Cloud-Giganten?](https://www.zdnet.de/88422391/trennt-sich-europa-von-den-us-cloud-giganten/) May 28, 2025 via ZDNet ![IT Daily logo](/static/it-daily-logo.png) ### [Trennt sich Europa von den US-Cloud-Giganten?](https://www.it-daily.net/it-management/cloud-computing/europa-us-cloud-giganten) May 28, 2025 via IT Daily ![Cloudcomputing Insider logo](/static/logo-1-.svg) ### [Rationaler Cloud-Betrieb in der produzierenden Industrie](https://www.cloudcomputing-insider.de/rationaler-cloud-betrieb-in-der-produzierenden-industrie-a-ee8b858ac184a65da2b8f148bb0dc4a7) May 7, 2025 via Cloudcomputing Insider ![Storage Consortium logo](/static/storageconsortium.png) ### [Berlin Institute of Health (BIH) vereinfacht Kubernetes-Management mit Hilfe von Kubermatic](https://storageconsortium.de/berlin-institute-of-health-bih-vereinfacht-kubernetes-management-mit-hilfe-von-kubermatic) May 7, 2025 via Storage Consortium ![e-health-com.de logo](/static/e-health-com.jpg) ### [Sichere Zusammenarbeit in der Pharmabranche durch föderierte KI – Kubermatic unterstützt mit skalierbarer Kubernetes-Infrastruktur](https://e-health-com.de/details-unternehmensnews/sichere-zusammenarbeit-in-der-pharmabranche-durch-foederierte-ki-kubermatic-unterstuetzt-mit-skalier/) May 6, 2025 via e-health-com.de ![Silicon Technology logo](/static/silicon.png) ### [Berlin Institute of Health (BIH) vereinfacht Kubernetes-Management mit Hilfe von Kubermatic](https://www.silicon.de/41719264/berlin-institute-of-health-bih-vereinfacht-kubernetes-management-mit-hilfe-von-kubermatic) May 6, 2025 via Silicon Technology ![Storage Consortium logo](/static/storageconsortium.png) ### [K8s Cluster Management: Kubermatic KubeOne 1.10 Unterstützung für Kubernetes 1.32](https://storageconsortium.de/k8s-cluster-management-kubermatic-kubeone-110-unterst%C3%BCtzung-f%C3%BCr-kubernetes-132) April 30, 2025 via Storage Consortium ![mit-blog.de logo](/static/mit-blog.png) ### [Schnelle Multi-Cloud-Migration bei der CNCF – Kubermatic unterstützt mit Cloud-übergreifender Lösung für Kubernetes](https://mit-blog.de/schnelle-multi-cloud-migration-bei-der-cncf-kubermatic-unterstuetzt-mit-cloud-uebergreifender-loesung-fuer-kubernetes/) April 25, 2025 via mit-blog.de ![thomasbarsch.de logo](/static/thomasbarsch.png) ### [Interne Entwicklerplattformen optimieren Softwareentwicklungseffizienz](https://thomasbarsch.de/blogs/blog/interne-entwicklerplattformen-optimieren-softwareentwicklungseffizienz) April 22, 2025 via thomasbarsch.de ### [Must-Have für Entwickler: Fünf entscheidende Vorteile interner Entwicklerplattformen](https://ap-verlag.de/must-have-fuer-entwickler-fuenf-entscheidende-vorteile-interner-entwicklerplattformen/95361/) April 22, 2025 via ap-verlag ![ITWELT logo](/static/itwelt-logo.png) ### [Fünf entscheidende Vorteile von internen Entwicklerplattformen](https://itwelt.at/news/fuenf-entscheidende-vorteile-von-internen-entwicklerplattformen/) April 17, 2025 via ITWELT ![IT Daily logo](/static/it-daily-logo.png) ### [Fünf entscheidende Vorteile interner Entwicklerplattformen](https://www.it-daily.net/it-management/digitalisierung/vorteile-interner-entwicklerplattformen) April 16, 2025 via IT Daily ![computerwoche.de logo](/static/computerwoche.svg) ### [14 alternative Managed-Kubernetes-Plattformen](https://www.computerwoche.de/article/3952263/14-alternative-managed-kubernetes-plattformen.html) April 15, 2025 via computerwoche.de ![IT Administrator logo](/static/it-administrator-logo.svg) ### [KubeCon + CloudNativeCon Europe 2025: Internal Developer Platform im Fokus](https://www.it-administrator.de/KubeCon-CloudNativeCon-Europe-2025) April 15, 2025 via IT Administrator ![thomasbarsch.de logo](/static/thomasbarsch.png) ### [Kubernetes Integration für effiziente Cloud-Lösungen](https://thomasbarsch.de/blogs/blog/kubernetes-integration-fur-effiziente-cloud-losungen) April 15, 2025 via thomasbarsch.de ### [Kubernetes-Integration: Rationalisierung des Cloud-Betriebs in der produzierenden Industrie](https://ap-verlag.de/kubernetes-integration-rationalisierung-des-cloud-betriebs-in-der-produzierenden-industrie/95117/) April 14, 2025 via ap-verlag ![IT Administrator logo](/static/it-administrator-logo.svg) ### [Container-Hafen](https://www.it-administrator.de/Container-Hafen-Kubermatic-Kubernetes-Plattform) April 1, 2025 via IT Administrator ![IP Insider logo](/static/ip-insider.svg) ### [Warum Unternehmen zunehmend in die Private Cloud fliehen](https://www.ip-insider.de/repatriation-unternehmen-verlagern-workloads-private-clouds-a-6b58282e95e77a3f6cbb308c6ce30251/) March 13, 2025 via IP Insider ![Platform Engineering logo](/static/platformengineering.png) ### [5 Crucial Benefits of Internal Developer Platforms](https://platformengineering.com/features/5-crucial-benefits-of-internal-developer-platforms/) March 4, 2025 via Platform Engineering ![IT Daily logo](/static/it-daily-logo.png) ### [Ein Blick in die Cloud-native-Kristallkugel](https://www.it-daily.net/spezial/weekend-special-cloud-computing/cloud-native) February 28, 2025 via IT Daily ![Data Center Insider logo](/static/logo-1-.svg) ### [Warum Unternehmen zunehmend in die Private Cloud fliehen](https://www.cloudcomputing-insider.de/private-cloud-vs-public-cloud-trend-a-5dbd0619264345bfc687dfcff7e1577c) February 7, 2025 via Data Center Insider ![Data Center Insider logo](/static/datacenter-insider.svg) ### ["Bezos API Mandate": Startschuss für die plattformgesteuerte Welt](https://www.datacenter-insider.de/bezos-api-mandate-technologieentwicklung-a-c9475a1822ad6bd87c7ccc52e5008a2a/) February 6, 2025 via Data Center Insider ### [Blick in die Cloud-native-Kristallkugel – Die Zukunft des Container-Managements](https://ap-verlag.de/blick-in-die-cloud-native-kristallkugel-die-zukunft-des-container-managements/93509/) February 4, 2025 via ap-verlag ![Cloudcomputing Insider logo](/static/logo-1-.svg) ### ["Bezos API Mandate": Startschuss für die plattformgesteuerte Welt](https://www.cloudcomputing-insider.de/-bezos-api-mandate-technologieentwicklung-a-07e3c4d168492a5c1a4cc0d2039ad479) February 4, 2025 via Cloudcomputing Insider ![ITWELT logo](/static/itwelt-logo.png) ### [Die Zukunft des Container-Managements](https://itwelt.at/news/topmeldung/die-zukunft-des-container-managements/) January 31, 2025 via ITWELT ### [Produktivität der Entwickler maximieren und Innovationen beschleunigen](https://ap-verlag.de/produktivitaet-der-entwickler-maximieren-und-innovationen-beschleunigen/93371/) January 31, 2025 via ap-verlag ![IT Daily logo](/static/it-daily-logo.png) ### [Die Bedeutung des "Bezos API Mandates" für moderne Plattformen](https://www.it-daily.net/it-management/e-business/die-bedeutung-des-bezos-api-mandates-fuer-moderne-plattformen) January 29, 2025 via IT Daily ![Storage Consortium logo](/static/storageconsortium.png) ### [Was ist Infrastructure Platform Engineering (IPE) und welche Rolle spielt Kubernetes?](https://storageconsortium.de/was-ist-infrastructure-platform-engineering-ipe-und-welche-rolle-spielt-kubernetes) January 24, 2025 via Storage Consortium ### [Warum Unternehmen sich zunehmend von der Public Cloud abwenden](https://ap-verlag.de/warum-unternehmen-sich-zunehmend-von-der-public-cloud-abwenden/93248/) January 23, 2025 via ap-verlag ![ITWELT logo](/static/itwelt-logo.png) ### [Trend zum Public-Cloud-Rückzug: Warum Unternehmen sich zunehmend abwenden](https://itwelt.at/news/topmeldung/trend-zum-public-cloud-rueckzug-warum-unternehmen-sich-zunehmend-abwenden/) January 21, 2025 via ITWELT ![Dev Insider logo](/static/dev-insider-logo.svg) ### [Kubermatic Developer Platform Entwickler stärken – mit dem Potenzial von Kubernetes](https://www.dev-insider.de/-kubermatic-developer-plattform-optimierte-entwicklung-a-f07554010be1e93cd0f8755258826396/) December 24, 2024 via Dev Insider ![Dev Insider logo](/static/dev-insider-logo.svg) ### [Automatisierte Bereitstellung und Verwaltung von Clustern Kubermatic stellt KubeOne 1.9 vor](https://www.dev-insider.de/kubermatic-aktualisiert-kubeone-kubernetes-und-ubuntu-unterstuetzung-a-2d669b031817563e4cffd1552122f203/) December 10, 2024 via Dev Insider ![Heise logo](/static/heise-online-logo.svg) ### [Developer Snapshots: Smaller news from last week](https://www.heise.de/news/Developer-Snapshots-Kleinere-News-der-letzten-Woche-10181773.html) November 30, 2024 via Heise ![IP Insider logo](/static/ip-insider.svg) ### [Cloud Native Load Balancing – Ohne "Multi-Tenant" nur die Hälfte wert](https://www.ip-insider.de/cloud-native-load-balancing-ohne-multi-tenant-nur-die-haelfte-wert-a-2ecc2d0d3979abb463136d3960c10bed/) November 20, 2024 via IP Insider ![Dev Insider logo](/static/dev-insider-logo.svg) ### [Kubermatic stellt Cloud Stack auf Open-Source-Basis vor](https://www.dev-insider.de/kubermatic-stellt-cloud-stack-auf-open-source-basis-vor-a-e98ce5ff31efd7268c7ffa9da8691323/) November 14, 2024 via Dev Insider ![Cloudcomputing Insider logo](/static/logo-1-.svg) ### [Kubermatic stellt Cloud Stack auf Open-Source-Basis vor](https://www.cloudcomputing-insider.de/kubermatic-stellt-cloud-stack-auf-open-source-basis-vor-a-b5a305851bdaa5ee09327f20adda689a/) November 12, 2024 via Cloudcomputing Insider ![Dev Insider logo](/static/dev-insider-logo.svg) ### [KKP 2.26: Optimiertes Bare-Metal-Kubernetes](https://www.dev-insider.de/neue-funktionen-kubermatic-kubernetes-platform-v2-26-a-6e65aa74f19fdc9fc7f9546793288b62/) November 5, 2024 via Dev Insider ![Dev Insider logo](/static/dev-insider-logo.svg) ### [Cloud Native Load Balancing – Ohne "Multi-Tenant" nur die Hälfte wert](https://www.dev-insider.de/cloud-native-load-balancing-ohne-multi-tenant-nur-die-haelfte-wert-a-352bd3dc431092550b463cf0a4201dce/) October 30, 2024 via Dev Insider ![TFIR logo](/static/tfir_image.png) ### [Troubleshooting with AI – How k8sgpt makes debugging Kubernetes clusters easie](https://tfir.io/troubleshooting-with-ai-how-k8sgpt-makes-debugging-kubernetes-clusters-easier/) October 8, 2024 via TFIR ![AutomationNext logo](/static/automation-next.jpg) ### [Warum Container die Zukunft der Fabrik-IT sind](/static/Automation_Next_2024.pdf) September 15, 2024 via AutomationNext ![Dev Insider logo](/static/dev-insider-logo.svg) ### [Ansätze für eine effiziente Kubernetes-Automatisierung](https://www.dev-insider.de/absicherung-container-umgebungen-kontinuierlicher-prozess-a-6add7b8b5787add277615637b16820fd/) September 11, 2024 via Dev Insider ![Professional System logo](/static/professional-system-logo.png) ### [Mit privaten 5G-Netzen fit für die Zukunft](https://www.professional-system.de/features/mit-privaten-5g-netzen-fit-fuer-die-zukunft/) September 8, 2024 via Professional System ![Storage Consortium logo](/static/storageconsortium.png) ### [Load Balancing in Kubernetes: Verbesserungen mit neuem KubeLB v1.1 Release von Kubermatic](https://storageconsortium.de/content/node/6007) September 4, 2024 via Storage Consortium ![IT Daily logo](/static/it-daily-logo.png) ### [Kubermatic mit KubeLB v1.1 Release für Load Balancing](https://www.it-daily.net/it-management/business-software/kubermatic-mit-kubelb-v1-1-release-fuer-load-balancing-in-kubernetes) August 29, 2024 via IT Daily ![IT Administrator logo](/static/it-administrator-logo.svg) ### [Optimiertes Loadbalancing für Kubernetes](https://www.it-administrator.de/Loadbalancing-fuer-Kubernetes) August 28, 2024 via IT Administrator ### [Orientierungshilfe: Vom Old Economy-Player zum Software-Unternehmen](https://ap-verlag.de/orientierungshilfe-vom-old-economy-player-zum-software-unternehmen/90319/) August 25, 2024 via ap-verlag ### [Datensicherheit und Datenschutz in Edge-Umgebungen](https://ap-verlag.de/datensicherheit-und-datenschutz-in-edge-umgebungen/90208/) August 17, 2024 via ap-verlag ![IT Daily logo](/static/it-daily-logo.png) ### [Datensicherheit und Datenschutz in Edge-Umgebungen](https://www.it-daily.net/it-sicherheit/datenschutz-grc/datenschutz-edge-umgebungen) August 16, 2024 via IT Daily ![Security Insider logo](/static/security-insider-logo.svg) ### [Kubernetes-Sicherheit muss in den Fokus](https://www.security-insider.de/cloud-native-technologie-kubernetes-sicherheit-a-49583b3b2a159679a63c9d0727e28378/) August 15, 2024 via Security Insider ![Cloudcomputing Insider logo](/static/logo-1-.svg) ### [Cloud-native Load Balancing – Ohne „Multi-Tenant” nur die Hälfte wert](https://www.cloudcomputing-insider.de/load-balancer-optimierung-microservices-cloud-native-technologien-a-0d67c7f718257015f87548004267da10/) August 14, 2024 via Cloudcomputing Insider ![IT-business logo](/static/it-business.svg) ### [Steigender Beratungsbedarf für Kubernetes](https://www.it-business.de/steigender-beratungsbedarf-fuer-kubernetes-a-6b168c6a8cad485d45546e1cf6b2670c/) August 7, 2024 via IT-business ![IT Daily logo](/static/it-daily-logo.png) ### [Was für den Schutz einer Container-Umgebung wichtig ist](https://www.it-daily.net/it-management/business-software/konzept-einer-sicheren-containerumgebung) August 7, 2024 via IT Daily ![Infopoint logo](/static/infopoint-security-logo.svg) ### [Kubermatic: Die Aufrechterhaltung einer sicheren Containerumgebung ist ein andauernder Prozess](https://www.infopoint-security.de/kubermatic-die-aufrechterhaltung-einer-sicheren-containerumgebung-ist-ein-andauernder-prozess/a37990/) August 6, 2024 via Infopoint ![Connect Professional logo](/static/connect-professional.svg) ### [Kubermatic: Sichere Containerumgebung](https://www.connect-professional.de/software-services/kubermatic-sichere-containerumgebung.330918.html) August 6, 2024 via Connect Professional ![IT Daily logo](/static/it-daily-logo.png) ### [Integration von KI und maschinellem Lernen in Kubernetes](https://www.it-daily.net/it-management/business-software/integration-von-ki-und-maschinellem-lernen-in-kubernetes) July 31, 2024 via IT Daily ![Healthcare digital logo](/static/healthcare-digital.svg) ### [Managed Kubernetes-as-a-Service in der Bioinformatik](https://www.healthcare-digital.de/managed-kubernetes-as-a-81fd4e121e3f5dfe10f561085bf509cd/) July 26, 2024 via Healthcare digital ![IT-business logo](/static/it-business.svg) ### [Volle Kraft voraus!](https://issuu.com/docs/0d4422cc22d42d16a142f46fd35822b4?fr=xPf9gYGA&mode=embed&pageNumber=50) July 22, 2024 via IT-business ![Dev Insider logo](/static/dev-insider-logo.svg) ### [Cloud-Native-Ambitionen erfordern ein Umdenken](https://www.dev-insider.de/cloud-native-trends-und-herausforderungen-in-der-containerisierung-und-kubernetes-a-c1d4454e49d1e0adfd5e8de40669387f/) July 18, 2024 via Dev Insider ![atp magazin logo](/static/atp-magazin.svg) ### [Container, Microservices und Kubernetes: Warum sie in Zukunft unverzichtbar sind.](https://4550048.fs1.hubspotusercontent-na1.net/hubfs/4550048/Marketing/atp_magazin_Container%2c%20Microservices%20und%20Kubernetes.pdf) July 15, 2024 via atp magazin ![AutomationNext logo](/static/automation-next.svg) ### [Warum Container die Zukunft der Fabrik-IT sind](https://www.automation-next.com/steuerung-it/warum-container-die-zukunft-der-fabrik-it-sind-824.html) June 17, 2024 via AutomationNext ![Dev Insider logo](/static/dev-insider-logo.svg) ### [Migration von VMware zu kosteneffizienter Kubernetes-Lösung](https://www.dev-insider.de/migration-von-vmware-zu-kosteneffizienter-kubernetes-loesung-a-1106dd9bb2a01a03da76dcac1301b1d6/) June 4, 2024 via Dev Insider ![IT-business logo](/static/it-business.svg) ### [Container Rangieren für große Cluster](https://www.it-business.de/container-rangieren-fuer-grosse-cluster-a-3a6e7f40f3d26c9a8c61b42713eca920/) May 21, 2024 via IT-business ![IT-business logo](/static/it-business.svg) ### [Container Rangieren für große Cluster](https://issuu.com/docs/1574ebeb10b3e9c090d6563bafd808bb?fr=xPf9gYGA&mode=embed&pageNumber=48) May 13, 2024 via IT-business ![Dev Insider logo](/static/dev-insider-logo.svg) ### [Orientierungshilfe für die EInführung von Kubernetes](https://www.dev-insider.de/ctos-guide-to-containers-and-kubernetes-top-10-faqs-a-ce61506baf4810c5cf71b31bf7cdc5ef/) May 10, 2024 via Dev Insider ![Storage Insider logo](/static/storage-insider.svg) ### [Migration von VMware zu kosteneffizienter Kubernetes-Lösung](https://www.storage-insider.de/migration-von-vmware-zu-kosteneffizienter-kubernetes-loesung-a-9bb4cdc3bd93bb011a56ea5c41880222/) May 8, 2024 via Storage Insider ![Storage Insider logo](/static/storage-insider.svg) ### [Wie sich mit einem Open-Source-Ansatz kritische Teile der VMware-Infrastrukturangebote durch eine kosteneffiziente Kubernetes-Lösung ersetzen lassen.](https://www.storage-insider.de/migration-von-vmware-zu-kosteneffizienter-kubernetes-loesung-a-9bb4cdc3bd93bb011a56ea5c41880222/) May 8, 2024 via Storage Insider ![IP Insider logo](/static/ip-insider.svg) ### [VMware: Nix wie weg!](https://www.ip-insider.de/nix-wie-weg-von-vmware-a-250adfafe622926ed4a7594e9f0bdeeb/) May 2, 2024 via IP Insider ![Industry of things logo](/static/industry-of-things.svg) ### [IoT und Kubernetes: Ist eine glückliche Ehe möglich?](https://www.industry-of-things.de/iot-und-kubernetes-ist-eine-glueckliche-ehe-moeglich-a-c53626e121da2bc505bfba8266f76dec/) May 2, 2024 via Industry of things ![elektrotechnik logo](/static/elektrotechnik.svg) ### [Sichere Cobots und schnelle Container](https://www.elektrotechnik.vogel.de/sichere-cobots-und-schnelle-containernbsp-a-653636d8a2155a235459b9d5abd9b21e/) April 25, 2024 via elektrotechnik ![AutomationNext logo](/static/automation-next.svg) ### [Sichere Cobots und schnelle Container – Zwischenfazit zur Hannover Messe](https://www.automation-next.com/kollegeroboter/sichere-cobots-und-schnelle-container-zwischenfazit-zur-hannover-messe-236.html) April 25, 2024 via AutomationNext ![IT-business logo](/static/it-business.svg) ### [VMware: Nix wie weg!](https://www.it-business.de/vmware-nix-wie-weg-a-1eb018bf9d6d28cdd4fdaa83b96ff4d9/) April 24, 2024 via IT-business ![Data Center Insider logo](/static/datacenter-insider.svg) ### [VMware: Nix wie weg!](https://www.datacenter-insider.de/vmware-nix-wie-weg-a-c7332a861ab8cab2ff876070c988b069/) April 22, 2024 via Data Center Insider ![ComputerWeekly.de logo](/static/computerweekly-logo.jpg) ### [Nach VMware-Übernahme: Welche Alternativen gibt es?](https://www.computerweekly.com/de/meinung/Nach-VMware-Uebernahme-Welche-Alternativen-gibt-es) April 17, 2024 via ComputerWeekly.de ![ITWELT logo](/static/itwelt-logo.png) ### [VMware by Broadcom: Sag beim Abschied leise Servus](https://itwelt.at/news/topmeldung/vmware-by-broadcom-sag-beim-abschied-leise-servus/) April 12, 2024 via ITWELT ![Silicon Technology logo](/static/silicon.png) ### [Migration von VMware zu einer kosteneffizienten Kubernetes-Lösung](https://www.silicon.de/41712925/migration-von-vmware-zu-einer-kosteneffizienten-kubernetes-loesung) April 6, 2024 via Silicon Technology ![Focus on: devops logo](/static/focusondevops.jpg) ### [Newsfolge 03/2024 CNCF Project Update, KubeLB und vieles mehr](https://focusondevops.podigee.io/89-new-episode) April 3, 2024 via Focus on: devops ![IT Daily logo](/static/it-daily-logo.png) ### [Auch Container brauchen Backups](https://www.it-daily.net/it-management/data-center/auch-container-brauchen-backups) April 3, 2024 via IT Daily ![Data Disrupted logo](/static/datadisrupted-logo.png) ### [#WorldBackupDay: Vier entscheidende Aspekte für das Backup von Containern](https://datadisrupted.tech/worldbackupday-vier-entscheidende-aspekte-fuer-das-backup-von-containern/) April 1, 2024 via Data Disrupted ### [World Backup Day: Auch Container brauchen Backup](https://ap-verlag.de/world-backup-day-auch-container-brauchen-backup/87540/) March 31, 2024 via ap-verlag ![IT Daily logo](/static/it-daily-logo.png) ### [World Backup Day 2024: Datenverlust vermeiden](https://www.it-daily.net/speicherguide/news-spg/world-backup-day-2024-datenverlust-vermeiden/3) March 31, 2024 via IT Daily ![Storage Consortium logo](/static/storageconsortium.png) ### [Kubermatic KubeLB Lösung zur Bereitstellung von Anwendungen in Cloud-nativen Umgebungen](https://storageconsortium.de/content/node/5892) March 27, 2024 via Storage Consortium ![lemagit logo](/static/lemag.png) ### [AIOps: quand l'IA générative s'invite dans la supervision de Kubernetes](https://www.lemagit.fr/actualites/366575437/AIOps-quand-lIA-generative-aide-a-superviser-Kubernetes) March 26, 2024 via lemagit ![Dev Insider logo](/static/dev-insider-logo.svg) ### [KubeLB von Kubermatic löst Load-Balancing-Probleme in K8s](https://www.dev-insider.de/kubermatic-kubelb-zentrale-lastverteilung-kubernetes-a-3d069437f5bbf39216361710aadd5a1f/) March 22, 2024 via Dev Insider ![Heise logo](/static/heise-online-logo.svg) ### [Developer Snapshots: Programmierer-News in ein, zwei Sätzen](https://www.heise.de/news/Developer-Snapshots-Programmierer-News-in-ein-zwei-Saetzen-9655631.html) March 15, 2024 via Heise ### [Vier Phasen für eine erfolgreiche VMware-Migration: Erkennen, Analysieren, Pilotieren und Planen](https://ap-verlag.de/vier-phasen-fuer-eine-erfolgreiche-vmware-migration-erkennen-analysieren-pilotieren-und-planen/87134/) March 15, 2024 via ap-verlag ![IT Daily logo](/static/it-daily-logo.png) ### [Vier Phasen für eine erfolgreiche VMware-Migration](https://www.it-daily.net/it-management/business-software/vier-phasen-fuer-eine-erfolgreiche-vmware-migration) March 12, 2024 via IT Daily ![SPS magazin logo](/static/sps-magazin-logo.png) ### [Wie Kubernetes, Industrie 4.0, Edge und Netzwerk zusammenhängen](https://www.sps-magazin.de/kommunikation/wie-kubernetes-industrie-4-0-edge-und-netzwerk-zusammenhaengen/) March 5, 2024 via SPS magazin ![IT Administrator logo](/static/it-administrator-logo.svg) ### [Edge Computing mithilfe von Kubernetes realisieren](https://www.it-administrator.de/Edge-Computing-mit-Kubernetes) January 30, 2024 via IT Administrator ![B2B cyber security logo](/static/b2b-cyber-security-logo.png) ### [NIS2 policy and container security](https://b2b-cyber-security.de/nis2-richtlinie-und-die-container-sicherheit/) January 29, 2024 via B2B cyber security ### [Besonders kleine Kubernetes-Cluster – Skalierung bis an den Rand des Möglichen](https://ap-verlag.de/besonders-kleine-kubernetes-cluster-skalierung-bis-an-den-rand-des-moeglichen/86167/) January 28, 2024 via ap-verlag ![JDN logo](/static/jdn-logo.webp) ### [Kubermatic, la plateforme qui simplifie Kubernetes](https://www.journaldunet.com/cloud/1527851-kubermatic-la-plateforme-qui-simplifie-kubernetes/) January 26, 2024 via JDN ![ComputerWeekly.de logo](/static/computerweekly-logo.jpg) ### [Container und Kubernetes im Jahr 2024](https://www.computerweekly.com/de/meinung/Container-und-Kubernetes-im-Jahr-2024) January 26, 2024 via ComputerWeekly.de ![IT Daily logo](/static/it-daily-logo.png) ### [Kleine Kubernetes-Cluster – Skalierung bis an den Rand des Möglichen](https://www.it-daily.net/it-management/data-center/kleine-kubernetes-cluster-skalierung-bis-an-den-rand-des-moeglichen) January 25, 2024 via IT Daily ![ITWELT logo](/static/itwelt-logo.png) ### [Kubermatic erläutert besonders kleine Kubernetes-Cluster – Skalierung bis an den Rand des Möglichen](https://itwelt.at/news/kubermatic-erlaeutert-besonders-kleine-kubernetes-cluster-skalierung-bis-an-den-rand-des-moeglichen/) January 23, 2024 via ITWELT ![Data Disrupted logo](/static/datadisrupted-logo.png) ### [Trend 2024: Bedarf an Containerplattformen steigt weiter; Fachkräftemangel beeinträchtigt Wettbewerbsfähigkeit](https://datadisrupted.tech/trend-2024-bedarf-an-containerplattformen-steigt-weiter-fachkraeftemangel-beeintraechtigt-wettbewerbsfaehigkeit/) January 23, 2024 via Data Disrupted ![Online PC logo](/static/onlinepc-logo.png) ### [Ausblicke zu Cloud Native und Kubernetes](https://www.onlinepc.ch/software/cloud/ausblicke-zu-cloud-native-kubernetes-2904594.html) January 20, 2024 via Online PC ### [Die Auswirkungen der NIS2-Richtlinie auf die Container-Sicherheit verstehen](https://ap-verlag.de/die-auswirkungen-der-nis2-richtlinie-auf-die-container-sicherheit-verstehen/85996/) January 18, 2024 via ap-verlag ![com! Magazine logo](/static/com-logo.png) ### [Ausblicke zu Cloud Native und Kubernetes](https://www.com-magazin.de/news/cloud/ausblicke-zu-cloud-native-kubernetes-2904213.html) January 17, 2024 via com! Magazine ![dotnetpro logo](/static/dotnetpro-logo.png) ### [Ausblicke zu Cloud Native und Kubernetes](https://www.dotnetpro.de/backend/cloud/ausblicke-zu-cloud-native-kubernetes-2903686.html) January 17, 2024 via dotnetpro ![Data Center Insider logo](/static/datacenter-insider.svg) ### [Eine Reise durch die Welt von Cloud Native und Kubernetes](https://www.datacenter-insider.de/2024-prognose-container-plattform-nachfrage-kubermatic-a-0cee8975682420c1a5936862ec9c6fc1/) January 15, 2024 via Data Center Insider ![IT Daily logo](/static/it-daily-logo.png) ### [Auswirkungen der NIS2-Richtlinie auf die Container-Sicherheit verstehen](https://www.it-daily.net/it-sicherheit/cloud-security/auswirkungen-der-nis2-richtlinie-auf-die-container-sicherheit-verstehen) January 15, 2024 via IT Daily ![Focus SVA logo](/static/focus-sva-logo.png) ### [Kubermatic exklusiv: Ein Blick voraus und zurück](https://focus.sva.de/devops/kubermatic-exklusiv-ein-blick-voraus-und-zurueck/) January 12, 2024 via Focus SVA ![Dev Insider logo](/static/dev-insider-logo.svg) ### [Eine Reise durch die Welt von Cloud Native und Kubernetes](https://www.dev-insider.de/2024-prognose-container-plattform-nachfrage-kubermatic-a-92ddeb6774cb92dff6585f31e95e1dca/) January 12, 2024 via Dev Insider ![Spreaker from iHeart logo](/static/spreaker-from-iheart-logo.svg) ### [How to scale k8s operations from a single to thousands of clusters](https://www.spreaker.com/episode/how-to-scale-k8s-operations-from-a-single-to-thousands-of-clusters--41464172) January 12, 2024 via Spreaker from iHeart ![IT Daily logo](/static/it-daily-logo.png) ### [Eine Reise durch die Welt von Cloud Native und Kubernetes](https://www.it-daily.net/it-management/cloud-computing/eine-reise-durch-die-welt-von-cloud-native-und-kubernetes) January 10, 2024 via IT Daily ![ICTk logo](/static/ictk-logo.png) ### [Container-Plattformen und Kubernetes vor signifikanten Veränderungen](https://ictk.ch/inhalt/container-plattformen-und-kubernetes-vor-signifikanten-ver%C3%A4nderungen) January 10, 2024 via ICTk ![ITWELT logo](/static/itwelt-logo.png) ### [Eine Reise durch die Welt von Cloud Native und Kubernetes](https://itwelt.at/news/eine-reise-durch-die-welt-von-cloud-native-und-kubernetes/) January 10, 2024 via ITWELT ![Dev Insider logo](/static/dev-insider-logo.svg) ### [Engpass bei Container-Experten?](https://www.dev-insider.de/kubermatic-prognose-boom-container-plattformen-2024-a-7504fccd3752423fadddb00e30fa1ab3/) December 29, 2023 via Dev Insider ![IT Daily logo](/static/it-daily-logo.png) ### [IT-Trends: Container und Kubernetes im Jahr 2024](https://www.it-daily.net/it-management/business-software/it-trends-container-und-kubernetes-im-jahr-2024) December 24, 2023 via IT Daily ![Computing for Geeks logo](/static/computing-for-geeks.png) ### [Deploy HA Kubernetes in Hetzner Cloud Using Kubermatic KubeOne](https://computingforgeeks.com/deploy-ha-kubernetes-in-hetzner-cloud-using-kubermatic-kubeone/) November 22, 2023 via Computing for Geeks ![Storage Consortium logo](/static/storageconsortium.png) ### [Container-Modernisierung: Interhyp verkürzt mit Kubermatic Time-to-Market auf eine Stunde](https://storageconsortium.de/content/node/5786) November 21, 2023 via Storage Consortium ![Public Manager logo](/static/public-manager.png) ### [WOBCOM baut den digitalen Backbone für die Smart City von Wolfsburg](https://www.public-manager.com/aktuelles/einzelansicht/archive/2023/november/article/wobcom-baut-den-digitalen-backbone-fuer-die-smart-city-von-wolfsburg.html) November 13, 2023 via Public Manager ### [Kubermatic verkürzt Time-to-Market – Kubermatic reduces time to market](https://security-storage-und-channel-germany.de/kubermatic-verkuerzt-time-to-market-kubermatic-reduces-time-to-market/) November 3, 2023 via Security Storage und Channel Germany - News for Information Technology ![IT Finanzmagazin logo](/static/IT-Finanzmagazin.png) ### [Interhyp verkürzt mit Kubermatic die Time-to-Market beim Datentransfer in die Cloud](https://www.it-finanzmagazin.de/interhyp-verkuerzt-mit-kubermatic-die-time-to-market-beim-datentransfer-in-die-cloud-163314/) November 3, 2023 via IT Finanzmagazin ![ComputerWeekly.de logo](/static/computerweekly-logo.jpg) ### [Container und Edge Computing auf dem Prüfstand](https://www.computerweekly.com/de/meinung/Container-und-Edge-Computing-auf-dem-Pruefstand) October 27, 2023 via ComputerWeekly.de ![Dev Insider logo](/static/dev-insider-logo.svg) ### ["Container sind eher noch ein 'Mainstream-Experten'-Thema"](https://www.dev-insider.de/rueckblick-containerdays-hybrid-event-2023-a-79f4968f5c3701fd77bec578d7ad1e28/) October 17, 2023 via Dev Insider ![Dev Insider logo](/static/dev-insider-logo.svg) ### [Container und Edge –das müssen Unternehmen beachten](https://www.dev-insider.de/edge-computing-kubernetes-huerden-ueberwindung-a-240a83ade0a890539a88e4acc79316ab/) September 26, 2023 via Dev Insider ![Data Center Insider logo](/static/datacenter-insider.svg) ### [Container und Edge: Das müssen Unternehmen beachten](https://www.datacenter-insider.de/container-und-edge-das-muessen-unternehmen-beachten-a-ee02f18caa0a2bb077450b5588e04448/) September 5, 2023 via Data Center Insider ![Dev Insider logo](/static/dev-insider-logo.svg) ### [Container-Sicherheit unter Kubernetes](https://www.dev-insider.de/container-sicherheit-kubernetes-defense-in-depth-ansatz-a-b88672caf0f56e9903006793b4f847f4/) August 22, 2023 via Dev Insider ![Security Insider logo](/static/security-insider-logo.svg) ### [Kubernetes-aaS und sicherer Zugang zu VMware-Cloud-Umgebungen](https://www.security-insider.de/kubernetes-aas-und-sicherer-zugang-zu-vmware-cloud-umgebungen-a-595cc711d1d808463b44199fc06777a6/) August 9, 2023 via Security Insider ![Security Insider logo](/static/security-insider-logo.svg) ### [Container-Sicherheit unter Kubernetes](https://www.security-insider.de/container-sicherheit-unter-kubernetes-a-d83ba46459a0241dcb1d6611c81af172/) August 9, 2023 via Security Insider ![Storage Consortium logo](/static/storageconsortium.png) ### [Management von Kubernetes-as-a-Service in der Multi Cloud auf Basis von Kubermatic KKP 2.23](https://storageconsortium.de/content/node/5680) July 25, 2023 via Storage Consortium ![Data Center Insider logo](/static/datacenter-insider.svg) ### [Kubernetes-aaS und sicherer Zugang zu VMware-Cloud-Umgebungen](https://www.datacenter-insider.de/kubernetes-aas-und-sicherer-zugang-zu-vmware-cloud-umgebungen-a-e9dca4d21dc1e9f9bf70d4b60192bb07/) July 17, 2023 via Data Center Insider ![IT Daily logo](/static/it-daily-logo.png) ### [Sysdig verkündet Partnerschaft mit Kubermatic](https://www.it-daily.net/shortnews/sysdig-verkuendet-partnerschaft-mit-kubermatic) June 29, 2023 via IT Daily ![Info Point Security logo](/static/infopoint-security-logo.svg) ### [Sysdig und Kubermatic kooperieren](https://www.infopoint-security.de/sysdig-und-kubermatic-kooperieren/a34686/) June 28, 2023 via Info Point Security ![Industrie.de logo](/static/industrie-de-vector-logo-press.png) ### [Sysdig gibt Partnerschaft mit Kubermatic bekannt](https://industrie.de/it-sicherheit/sysdig-gibt-partnerschaft-mit-kubermatic-bekannt/) June 28, 2023 via Industrie.de ![ComputerWeekly.de logo](/static/computerweekly-logo.jpg) ### [Die Herausforderungen bei der Container-Sicherheit](https://www.computerweekly.com/de/meinung/Die-Herausforderungen-bei-der-Container-Sicherheit) June 20, 2023 via ComputerWeekly.de ![dotnetpro logo](/static/dotnetpro-logo.png) ### [Container im Visier von Cyberangreifern](https://www.dotnetpro.de/core/sicherheit/container-im-visier-cyberangreifern-2862650.html) May 26, 2023 via dotnetpro ![Computerworld Switzerland logo](/static/computerworld-switzerland-logo.png) ### [Container im Visier von Cyberangreifern](https://www.computerworld.ch/security/business-it/container-im-visier-cyberangreifern-2862735.html) May 26, 2023 via Computerworld Switzerland ![InfoPoint Security logo](/static/infopoint-security-logo.svg) ### [Sparzwang als Chance für mehr Effizienz – Container-Orchestrierung spart Energie](https://www.infopoint-security.de/sparzwang-als-chance-fuer-mehr-effizienz-container-orchestrierung-spart-energie/a32777/) November 23, 2022 via InfoPoint Security ![Techvisor logo](/static/techvisor.png) ### [Stijgende energieprijzen, een duw in de rug om te verduurzamen!](https://www.techvisor.nl/Artikelen/9513/stijgende-energieprijzen-een-duw-in-de-rug-om-te-verduurzamen) November 23, 2022 via Techvisor ![Techvisor logo](/static/techvisor.png) ### [Energy is Key](https://www.techvisor.nl/Marktplaats/1606/energy-is-key) November 23, 2022 via Techvisor ![Silicon Technology logo](/static/silicon.png) ### [Energie-Einsparpotential von Kubernetes über 30 Prozent](https://www.silicon.de/41702724/energie-einsparpotential-von-kubernetes-ueber-30-prozent) November 22, 2022 via Silicon Technology ![Channel Web logo](/static/channelweb.png) ### [Kubermatic start Europese expansie in Nederland](https://www.channelweb.nl/artikel/techwire/start-ups/7432918/5249075/kubermatic-start-europese-expansie-in-nederland.html) November 10, 2022 via Channel Web ![Baaz logo](/static/baaz.png) ### [Kubermatic start Europese expansie in Nederland](https://www.baaz.nl/kubermatic-start-europese-expansie-in-nederland) November 9, 2022 via Baaz ![Dutch IT-Channel logo](/static/dutchitchannel.png) ### [Kubermatic start Europese expansie in Nederland](https://dutchitchannel.nl/708721/kubermatic-start-europese-expansie-in-nederland.html) November 9, 2022 via Dutch IT-Channel ![Executive-People logo](/static/executive-people.png) ### [Kubermatic start Europese expansie in Nederland](https://executive-people.nl/708721/kubermatic-start-europese-expansie-in-nederland.html) November 9, 2022 via Executive-People ![Techzine logo](/static/techzine-logo-news.jpg) ### [Kubermatic breidt uit naar Nederland](https://www.techzine.nl/nieuws/devops/508260/kubermatic-breidt-uit-naar-nederland/) November 8, 2022 via Techzine ![Emerce logo](/static/emerce.png) ### [Kubermatic start Europese expansie in Nederland](https://www.emerce.nl/wire/kubermatic-start-europese-expansie-nederland) November 8, 2022 via Emerce ![Techvisor logo](/static/techvisor.png) ### [Kubermatic start Europese expansie in Nederland](https://www.techvisor.nl/Artikelen/9351/kubermatic-start-europese-expansie-in-nederland) November 8, 2022 via Techvisor ![Channel Connect logo](/static/channel-connect.jpg) ### [Kubermatic start Europese expansie in Nederland](https://www.channelconnect.nl/datacenter-en-cloud/kubermatic-start-europese-expansie-in-nederland/) November 8, 2022 via Channel Connect ![Computable NL logo](/static/computable.png) ### [Kubermatic: Kubernetes wint terrein bij telecom](https://www.computable.nl/artikel/achtergrond/technologie/7429680/5182002/kubermatic-kubernetes-wint-terrein-bij-telecom.html) November 3, 2022 via Computable NL ![Computable BE logo](/static/computable-be.png) ### [Kubermatic: Kubernetes wint terrein bij telecom](https://www.computable.be/artikel/achtergrond/technologie/7429680/5742033/kubermatic-kubernetes-wint-terrein-bij-telecom.html) November 3, 2022 via Computable BE ![Dev Insider logo](/static/dev-insider-logo.svg) ### [Bekenntnis zur Open Source Community. Kubermatic wird Mitglied der Linux Foundation Europe](https://www.dev-insider.de/kubermatic-wird-mitglied-der-linux-foundation-europe-a-5db014c45f1e1192a0bee3bbe4b1192f/) October 28, 2022 via Dev Insider ![Data Center Insider logo](/static/datacenter-insider.svg) ### [Softwarebasiert die Effizienz erhöhen. Kubermatic: Mit Containern zu schnellen Energie-Einsparungen](https://www.datacenter-insider.de/kubermatic-mit-containern-zu-schnellen-energie-einsparungen-a-8703393390be4a8e84d68a434ec4bd6a/) October 25, 2022 via Data Center Insider ![Heise logo](/static/heise-online-logo.svg) ### [Developer Snapshots: Programmierer-News in ein, zwei Sätzen](https://www.heise.de/news/Developer-Snapshots-Programmierer-News-in-ein-zwei-Saetzen-7316092.html) October 21, 2022 via Heise ![Infopoint logo](/static/infopoint-security-logo.svg) ### [Kubermatic wird Mitglied der Linux Foundation Europe](https://www.infopoint-security.de/kubermatic-wird-mitglied-der-linux-foundation-europe/a32516/) October 21, 2022 via Infopoint ![IT Daily logo](/static/it-daily-logo.png) ### [Energieeffizienz im Rechenzentrum – Mit Software und Containern mehr erreichen](https://www.it-daily.net/it-management/data-center/energieeffizienz-im-rechenzentrum-mit-software-und-containern-mehr-erreichen) October 12, 2022 via IT Daily ![Business Punk logo](/static/business-punk-logo.svg) ### [Business Punk und Statista präsentieren die Top-Startup-Arbeitgeber 2022](https://www.business-punk.com/2022/10/business-punk-und-statista-praesentieren-die-top-startup-arbeitgeber-2022/2/) October 11, 2022 via Business Punk ![Dev Insider logo](/static/dev-insider-logo.svg) ### [Container Days locken Tausend der Cloud-native Community. Kubermatic und Partner bekommen Kubernetes-Cluster in den Griff](https://www.dev-insider.de/kubermatic-und-partner-bekommen-kubernetes-cluster-in-den-griff-a-053cab3dd737ad056bcb61d7b88ad4aa/) September 28, 2022 via Dev Insider ![Dutch IT-Channel logo](/static/dutchitchannel.png) ### [Kubermatic Kubernetes Platform ondersteunt meer providers en OS'en](https://dutchitchannel.nl/705247/kubermatic-kubernetes-platform-vernieuwd.html) September 26, 2022 via Dutch IT-Channel ![Executive-People logo](/static/executive-people.png) ### [Kubermatic Kubernetes Platform vernieuwd](https://executive-people.nl/705247/kubermatic-kubernetes-platform-vernieuwd.html) September 26, 2022 via Executive-People ![Data Center Insider logo](/static/datacenter-insider.svg) ### [Container Days locken Tausend der Cloud-native Community. Kubermatic, Luminis und Novatec bekommen Kubernetes-Cluster in den Griff](https://www.datacenter-insider.de/kubermatic-luminis-und-novatec-bekommen-kubernetes-cluster-in-den-griff-a-e6c7a0c349860febe87e9e29d727ae41/) September 15, 2022 via Data Center Insider ![Computerworld Switzerland logo](/static/computerworld-switzerland-logo.png) ### [Kubernetes-Plattform KKP 2.21 vorgestellt](https://www.computerworld.ch/business/business-software/kubernetes-plattform-kkp-221-vorgestellt-2797927.html) September 14, 2022 via Computerworld Switzerland ![dotnetpro logo](/static/dotnetpro-logo.png) ### [Kubernetes-Plattform KKP 2.21 vorgestellt](https://www.dotnetpro.de/update/kubernetes-plattform-kkp-221-vorgestellt-2795799.html) September 13, 2022 via dotnetpro ![com! Magazine logo](/static/com-logo.png) ### [Kubernetes-Plattform KKP 2.21 vorgestellt](https://www.com-magazin.de/news/devops/kubernetes-plattform-kkp-221-vorgestellt-2797867.html) September 13, 2022 via com! Magazine ![Dev Insider logo](/static/dev-insider-logo.svg) ### [Neue Version der Kubermatic Kubernetes Platform. KKP 2.21: Tausende Kubernetes-Cluster automatisieren](https://www.dev-insider.de/kkp-221-tausende-kubernetes-cluster-automatisieren-a-181a4d4a593e347afc6f655f1e42689c/) September 12, 2022 via Dev Insider ![Dev Insider logo](/static/dev-insider-logo.svg) ### [Neues von den Container Days 2022. Kubernetes geht in die Multi-Cloud und erobert das Edge](https://www.dev-insider.de/kubernetes-geht-in-die-multi-cloud-und-erobert-das-edge-a-91821178495f058177354b0d7f3f59b7/) September 9, 2022 via Dev Insider ![LanLine logo](/static/lanline-logo.svg) ### [Kubermatic Kubernetes Platform in aktualisierter Version. Grenzen zwischen Edge und Cloud verschieben sich](https://www.lanline.de/it-management/grenzen-zwischen-edge-und-cloud-verschieben-sich.254718.html) September 7, 2022 via LanLine ![BI Platform logo](/static/bi-platform.jpg) ### [Kubermatic Kubernetes Platform verlegt grenzen tussen de Edge en Cloud](https://biplatform.nl/2663608/kubermatic-kubernetes-platform-verlegt-grenzen-tussen-de-edge-en-cloud.html) September 6, 2022 via BI Platform ![Release logo](/static/release.jpg) ### [Kubermatic Kubernetes Platform verlegt grenzen tussen de Edge en Cloud](https://release.nl/2663608/kubermatic-kubernetes-platform-verlegt-grenzen-tussen-de-edge-en-cloud.html) September 6, 2022 via Release ![TEQ Nation logo](/static/teq-nation.png) ### [Nieuw Kubermatic Kubernetes Platform (KKP) verlegt grenzen tussen de Edge en Cloud](https://news.teqnation.com/nieuw-kubermatic-kubernetes-platform-kkp-verlegt-grenzen-tussen-de-edge-en-cloud/) September 6, 2022 via TEQ Nation ![Channel Web logo](/static/channelweb.png) ### [Nieuw Kubermatic Kubernetes Platform verlegt grenzen tussen Edge en Cloud](https://www.channelweb.nl/artikel/techwire/cloud-computing/7407913/5249075/nieuw-kubermatic-kubernetes-platform-verlegt-grenzen-tussen-edge-en-cloud.html) September 6, 2022 via Channel Web ![Techvisor logo](/static/techvisor.png) ### [Nieuw Kubermatic Kubernetes Platform (KKP) verlegt grenzen tussen de Edge en Cloud](https://www.techvisor.nl/Artikelen/8696/nieuw-kubermatic-kubernetes-platform-kkp-verlegt-grenzen-tussen-de-edge-en-cloud) September 5, 2022 via Techvisor ![Computable logo](/static/computable.png) ### [Nieuw Kubermatic Kubernetes Platform verlegt grenzen tussen Edge en Cloud](https://www.computable.nl/artikel/techwire/cloud-computing/7407913/2499347/nieuw-kubermatic-kubernetes-platform-verlegt-grenzen-tussen-edge-en-cloud.html) September 5, 2022 via Computable ![Emerce logo](/static/emerce.png) ### [Nieuw Kubermatic Kubernetes Platform (KKP) verlegt grenzen tussen de Edge en Cloud](https://www.emerce.nl/wire/nieuw-kubermatic-kubernetes-platform-kkp-verlegt-grenzen-tussen-edge-cloud) September 5, 2022 via Emerce ![The Free Press Journal logo](/static/the-free-press-journal-logo.png) ### [NetApp Excellerator announces Cohort 10](https://www.freepressjournal.in/business/netapp-excellerator-announces-cohort-10) April 28, 2022 via The Free Press Journal ![Enterprise Talk logo](/static/blog-logo-enterprisetalk-press.png) ### [SVA Software Allies With Kubermatic for Kubernetes Cloud Automation](https://enterprisetalk.com/news/sva-software-allies-with-kubermatic-for-kubernetes-cloud-automation/) March 11, 2022 via Enterprise Talk ![The New Stack logo](/static/the-new-stack-logo-1-.svg) ### [Kubermatic Assumes More Kubernetes-Management Heavy Lifting](https://thenewstack.io/kubermatic-assumes-more-kubernetes-management-heavy-lifting/) February 28, 2022 via The New Stack ![Industrie.de logo](/static/industrie-de-vector-logo-press.png) ### [Technischer Baukasten soll 5G-Campusnetze flexibel nutzbar machen](https://industrie.de/5g-mobilfunkstandard/technischer-baukasten-5g-campusnetze-industrie-flexibel-nutzbar/) February 23, 2022 via Industrie.de ![heise online logo](/static/heise-online-logo.svg) ### [Cluster einfacher verwalten: Mit KubeOne 1.4 und einem API-Update](https://www.heise.de/news/Cluster-einfacher-verwalten-Mit-KubeOne-1-4-und-einem-API-Update-6497175.html) February 18, 2022 via heise online ![Heise Online logo](/static/heise-online-logo.svg) ### [Kubermatic Kubernetes Platform 2.19 Verwaltet Externe Cluster](https://www.heise.de/news/Kubermatic-Kubernetes-Platform-2-19-verwaltet-externe-Cluster-6339575.html) January 26, 2022 via Heise Online ![Dev Insider logo](/static/dev-insider-logo.svg) ### [Kubermatic Kubernetes Platform 2.19 verfügbar](https://www.dev-insider.de/kubermatic-kubernetes-platform-219-verfuegbar-a-1089966/) January 26, 2022 via Dev Insider ![Techzine logo](/static/techzine-logo-news.jpg) ### [Kubermatic Lanceert KPP 2.19 Voor Multi-Cloud Clusterbeheer](https://www.techzine.nl/nieuws/devops/475949/kubermatic-lanceert-kpp-2-19-voor-multi-cloud-clusterbeheer/) January 25, 2022 via Techzine ![EdgeIR logo](/static/edgeir-logo-news.png) ### [Kubermatic Raises $6 Million to Further Development of Kubernetes Platform](https://www.edgeir.com/kubermatic-raises-6-million-to-further-development-of-kubernetes-platform-20220124) January 24, 2022 via EdgeIR ![Hamburg Startups logo](/static/hamburg-startups-logo_rgb.png) ### [Kubermatic Erhöht Seed-Finanzierung um 2,3 Millionen US-Dollar](https://www.hamburg-startups.net/kubermatic-erhoeht-seed-finanzierung-um-23-millionen-us-dollar/) January 19, 2022 via Hamburg Startups ![Venture Beat logo](/static/logo-venturebeat_vb.png) ### [30 Startups That Show How Open Source Ate the World in 2021](https://venturebeat.com/2022/01/03/30-startups-that-show-how-open-source-ate-the-world-in-2021/) January 4, 2022 via Venture Beat ![Gründerszene logo](/static/gruenderszene-logo-press.png) ### [Remote Hiring: Wie kann man Mitarbeiter im Ausland beschäftigen?](https://www.businessinsider.de/gruenderszene/karriere-startup/remote-hiring-mitarbeiter-im-ausland-beschaeftigen-b/) December 2, 2021 via Gründerszene ![Best Startup.eu logo](/static/logo_best-startup-eu.png) ### [101 Top Enterprise Startups and Companies in Germany](https://beststartup.eu/101-top-enterprise-startups-and-companies-in-germany/) November 24, 2021 via Best Startup.eu ![Gründerszene logo](/static/gruenderszene-logo-press.png) ### [Weshalb Das Software-Startup Kubermatic Erst Fünf Jahre Nach Start Millionen Einsammelt](https://www.businessinsider.de/gruenderszene/business/weshalb-das-software-startup-kubermatic-erst-fuenf-jahre-nach-start-millionen-einsammelt/) November 12, 2021 via Gründerszene ![Hosting Journalist logo](/static/logo-Hosting-Journalists-54514911_2149425588426235_7348359640939233280_n.png) ### [Kubermatic Raises $6M to Accelerate Growth of Its Kubernetes Platform](https://hostingjournalist.com/kubermatic-raises-6m-to-accelerate-growth-of-its-kubernetes-platform/) November 10, 2021 via Hosting Journalist ![Hamburg Startups logo](/static/hamburg-startups-logo_rgb.png) ### [Kubermatic Sichert Sich 6 Millionen Us-Dollar in Seed-Finanzierung](https://www.hamburg-startups.net/kubermatic-sichert-sich-6-millionen-us-dollar-in-seed-finanzierung/) November 10, 2021 via Hamburg Startups ![Techzine logo](/static/techzine-logo-news.jpg) ### [Clusterbeheertool Kubermatic Groeit Dankzij Miljoeneninvestering](https://www.techzine.nl/nieuws/cloud/470086/clusterbeheertool-kubermatic-groeit-dankzij-miljoeneninvestering/) November 10, 2021 via Techzine ![VentureBeat logo](/static/logo-venturebeat_vb.png) ### [How Kubermatic Helps Automate Kubernetes Across Any Infrastructure](https://venturebeat.com/business/how-kubermatic-helps-automate-kubernetes-across-any-infrastructure/) November 10, 2021 via VentureBeat ![Business Wire logo](/static/logo_business-wire-india.png) ### [Europäische Unternehmen setzen vermehrt auf Container, um die App-Entwicklung zu beschleunigen](https://www.businesswire.com/news/home/20211013005935/de/) October 13, 2021 via Business Wire ![Datacenter Insider logo](/static/datacenter-insider.svg) ### [Cluster-Lifecycle-Management in Cloud-, On-Prem-, Edge- und IoT-Umgebungen](https://www.datacenter-insider.de/cluster-lifecycle-management-in-cloud-on-prem-edge-und-iot-umgebungen-a-1056656/) September 27, 2021 via Datacenter Insider ![Cloud7 News logo](/static/logo-cloud7-news.jpg) ### [KubeOne 1.3 Makes the Life Easier!](https://cloud7.news/cloud/kubeone-1-3-makes-the-life-easier/) September 27, 2021 via Cloud7 News ![The New Stack logo](/static/the-new-stack-logo-1-.svg) ### [Kubermatic Kubernetes Platform Beats Complexity Through Automation](https://thenewstack.io/kubermatic-kubernetes-platform-beats-complexity-through-automation/) September 22, 2021 via The New Stack ![Digital Journal logo](/static/digital-journal-logo.png) ### [Kubermatic Kubernetes Platform 2.18 Delivers Streamlined Operations Across Highly Complex Multi-Cloud Environments](https://www.digitaljournal.com/pr/kubermatic-kubernetes-platform-2-18-delivers-streamlined-operations-across-highly-complex-multi-cloud-environments) September 15, 2021 via Digital Journal ![Business Wire India logo](/static/logo_business-wire-india.png) ### [Kubermatic Partners With DifiNative to Deliver Best-in-Class Services](https://www.businesswireindia.com/kubermatic-partners-with-difinative-to-deliver-best-in-class-services-73775.html) July 1, 2021 via Business Wire India ![Container Journal logo](/static/logo-containerjournal_11ofcuc__400x400.jpg) ### [Kubermatic K8s Platform 2.17 Automates Multi-Cluster Backups](https://containerjournal.com/features/kubermatic-k8s-platform-2-17-automates-multi-cluster-backups/) May 21, 2021 via Container Journal ![Techzine logo](/static/techzine-logo-news.jpg) ### [Kubermatic voegt back-up en replicatie toe aan Kubernetes-platform](https://www.techzine.nl/nieuws/cloud/459927/kubermatic-voegt-back-up-en-replicatie-toe-aan-kubernetes-platform/) May 21, 2021 via Techzine ![DevClass logo](/static/devclass_logo_black_small-horizontal.png) ### [Kubermatic Kubernetes Platform 2.17 intros automated backup and restore](https://devclass.com/2021/04/30/kubermatic-kubernetes-platform-2-17-intros-automated-backup-and-restore/) April 30, 2021 via DevClass ![cloud7 logo](/static/logo-cloud7-news.jpg) ### [Kubermatic Kubernetes Platform 2.17 released!](https://cloud7.news/cloud/kubermatic-kubernetes-platform-2-17-released/) April 29, 2021 via cloud7 ![Cloud7 logo](/static/logo-cloud7-news.jpg) ### [Kubermatic releases KubeOne 1.2](https://cloud7.news/cloud/kubermatic-releases-kubeone-1-2/) March 26, 2021 via Cloud7 ![heise online logo](/static/heise-online-logo.svg) ### [Cluster-Lifecycle-Management-Tool: KubeOne 1.2 ist erschienen](https://www.heise.de/news/Cluster-Lifecycle-Management-Tool-KubeOne-1-2-ist-erschienen-5996763.html) March 24, 2021 via heise online ![Bytes for Business logo](/static/logo_bytes-for-business.png) ### [Die Zukunft des Cloud-Computing: Interview mit Julian Hansert, Co-Founder von Kubermatic](https://bytesforbusiness.com/die-zukunft-des-cloud-computing-interview-mit-julian-hansert-co-founder-von-kubermatic/) March 21, 2021 via Bytes for Business ![Container Journal logo](/static/logo-containerjournal_11ofcuc__400x400.jpg) ### [Kubermatic Kubernetes Platform Supports OPA Integration](https://containerjournal.com/features/how-kubermatic-kubernetes-platform-supports-opa-integration/) February 25, 2021 via Container Journal ![DevClass logo](/static/devclass_logo_black_small-horizontal.png) ### [Edge is getting crowded: Kubermatic Kubernetes Platform 2.16 adds ARM, OPA, ML support](https://devclass.com/2021/02/11/kkp-2_16-kubermatic/) February 11, 2021 via DevClass ![heise online logo](/static/heise-online-logo.svg) ### [Cloud-native: Kubermatic Kubernetes Platform 2.16 integriert Open Policy Agent](https://www.heise.de/news/Cloud-native-Kubermatic-Kubernetes-Platform-2-16-integriert-Open-Policy-Agent-5052488.html) February 11, 2021 via heise online ![Container Journal logo](/static/logo-containerjournal_11ofcuc__400x400.jpg) ### [Kubermatic Updates Control Plane for Kubernetes](https://containerjournal.com/features/kubermatic-updates-control-plane-for-kubernetes/) February 10, 2021 via Container Journal ![Cision logo](/static/logo_cision-pr-newswire.jpg) ### [Kubermatic Kubernetes Platform 2.16 Delivers on State of The-Art Policy Enforcement](https://www.prnewswire.com/news-releases/kubermatic-kubernetes-platform-2-16-delivers-on-state-of-the-art-policy-enforcement-301225567.html) February 10, 2021 via Cision ![Hamburg News logo](/static/logo_hamburg-news.png) ### [Kubermatic entwickelt sich trotz und wegen der Pandemie positiv](https://hamburg-news.hamburg/unternehmen/kubermatic-entwickelt-sich-trotz-und-wegen-der-pandemie-positiv) January 11, 2021 via Hamburg News ![Cloud7 logo](/static/logo-cloud7-news.jpg) ### [Interview: Sebastian Scheele, CEO and Co-founder, Kubermatic](https://cloud7.news/interview/interview-sebastian-scheele-ceo-and-co-founder-kubermatic/) December 9, 2020 via Cloud7 ![EuroCloud Deutschland logo](/static/logo_eurocloud-deutschland.png) ### [EuroCloud Native-Mitglieder im Interview: Kubermatic](https://www.eurocloudnative.de/eurocloud-native-mitglieder-im-interview-kubermatic/) December 7, 2020 via EuroCloud Deutschland ![CRN logo](/static/logo_crn.jpg) ### [The 10 Hottest Kubernetes Startups Of 2020](https://www.crn.com/slide-shows/cloud/the-10-hottest-kubernetes-startups-of-2020/5?utm_source=hs_email&utm_medium=email&_hsenc=p2ANqtz-_2MgXf3SPNnU5MXZa1wc1m26sdX8pGt7tuTO-2CgacfVbbsL7oNaLZlvku42s2ftoMAwJW) November 20, 2020 via CRN ![Container Journal logo](/static/cropped-containerjournallogostacked-1024x276.jpg) ### [Kubermatic Releases KubeOne 1.1: New Autoscaler Helps Optimize Resource Usage](https://containerjournal.com/news/news-releases/kubermatic-releases-kubeone-1-1-new-autoscaler-helps-optimize-resource-usage/) November 17, 2020 via Container Journal ![InfoQ logo](/images/press/infoq.jpg) ### [Kubermatic Announces Open Source Service Hub KubeCarrier](https://www.infoq.com/news/2020/10/kubermatic-announces-kubecarrier/) October 27, 2020 via InfoQ ![Cloud7 logo](/static/logo-cloud7-news.jpg) ### [Kubermatic introduces Kubernetes Platform 2.15](https://cloud7.news/cloud/kubermatic-introduces-kubernetes-platform-2-15/) October 22, 2020 via Cloud7 ![DevClass logo](/static/devclass_logo_black_small-horizontal.png) ### [Let the right one in: Kubermatic Kubernetes Platform hits 2.15 with external cluster support, new installer](https://devclass.com/2020/10/22/kubermatic-kubernetes-platform-2_15/) October 22, 2020 via DevClass ![heise online logo](/static/heise-online-logo.svg) ### [Cloud-native: Kubermatic Kubernetes Platform 2.15 bindet externe Cluster ein](https://www.heise.de/news/Cloud-native-Kubermatic-Kubernetes-Platform-2-15-bindet-externe-Cluster-ein-4934984.html) October 21, 2020 via heise online ![Container Journal logo](/static/cropped-containerjournallogostacked-1024x276.jpg) ### [Kubermatic Joins 5G Consortium to Advance Kubernetes Adoption](https://containerjournal.com/topics/container-networking/kubermatic-joins-5g-consortium-to-advance-kubernetes-adoption/) September 21, 2020 via Container Journal ![VentureBeat logo](/static/logo-venturebeat_vb.png) ### [Major pharma companies, including Novartis and Merck, build federated learning platform for drug discovery](https://venturebeat.com/ai/major-pharma-companies-including-novartis-and-merck-build-federated-learning-platform-for-drug-discovery/) September 17, 2020 via VentureBeat ![TelecomDrive logo](/static/Logo-Telecom-Drive.PNG) ### [5G Open Innovation Lab Selects Kubermatic to Drive Innovation on 5G](https://telecomdrive.com/5g-open-innovation-lab-selects-kubermatic-to-drive-innovation-on-5g/) September 17, 2020 via TelecomDrive ![JAXenter logo](/static/jaxenter-logo.png) ### [Cluster Lifecycle Management: Open-Source-Tool KubeOne 1.0 veröffentlicht](https://entwickler.de/kubernetes/cluster-lifecycle-management-open-source-tool-kubeone-10-veroffentlicht-001/) September 8, 2020 via JAXenter ![TechGenix logo](/static/techgenix-logo.png) ### [Hot Kubernetes Startups Rancher, Kubermatic, and Kublr Bring the Heat](https://techgenix.com/rancher-kubermatic-and-kublr-kubernetes-startups/) September 4, 2020 via TechGenix ![DevClass logo](/static/devclass_logo_black_small-horizontal.png) ### [What’s the point: Istio governance, CircleCI, Algorithmia, GraalVM, and KubeOne](https://devclass.com/2020/08/25/wtp-250820-news-roundup/) August 25, 2020 via DevClass ![Forbes logo](/static/forbes-logo-6-1.png) ### [5 Interesting Announcements From KubeCon+CloudNativeCon Europe 2020](https://www.forbes.com/sites/janakirammsv/2020/08/23/5-interesting-announcements-from-kubeconcloudnativecon-europe-2020/#2e0f02b95320) August 23, 2020 via Forbes ![heise online logo](/static/heise-online-logo.svg) ### [Cluster-Lifecycle-Management: KubeOne erreicht Version 1.0](https://www.heise.de/news/Cluster-Lifecycle-Management-KubeOne-erreicht-Version-1-0-4873984.html) August 19, 2020 via heise online ![ITOps Times logo](/static/ipopstimes-logo.png) ### [KubeCon + CloudNativeCon EU: Carbon Relay releases Red Sky Ops free edition, Cloudtamer.io and Kublr announce integration, and more](https://www.itopstimes.com/itops/kubecon-cloudnativecon-eu-carbon-relay-releases-red-sky-ops-free-edition-cloudtamer-io-and-kublr-announce-integration-and-more/) August 18, 2020 via ITOps Times ![The New Stack logo](/static/the-new-stack-logo-1-.svg) ### [Kubermatic KubeCarrier Readies a Single Interface for Multiclusters and Multiclouds](https://thenewstack.io/kubermatic-kubecarrier-readies-a-single-interface-for-multiclusters-and-multiclouds/) August 11, 2020 via The New Stack ![Hamburg Startups logo](/static/hamburg-startups-logo_rgb.png) ### [Kubermatic – Hamburger Container-Technik für die IT-Welt](https://www.hamburg-startups.net/kubermatic-hamburger-container-technik-fuer-die-it-welt/) August 11, 2020 via Hamburg Startups ![Hosting Journalist logo](/static/logo-Hosting-Journalists-54514911_2149425588426235_7348359640939233280_n.png) ### [Kubermatic Unveils KubeCarrier to Deliver Cloud-Native Service Management at Scale](https://hostingjournalist.com/kubermatic-unveils-kubecarrier-to-deliver-cloud-native-service-management-at-scale/) August 8, 2020 via Hosting Journalist ![ITOps Times logo](/static/ipopstimes-logo.png) ### [ITOps Times Open-Source Project of the Week: KubeCarrier](https://www.itopstimes.com/itops/itops-open-source-project-of-the-week-kubecarrier/) August 7, 2020 via ITOps Times ![VMBlog.com logo](/static/logo-vmblog-208880_250300868420574_1908068558_n.jpg) ### [Kubermatic Launches KubeCarrier to Deliver Cloud Native Service Management at Scale with Kubernetes Operators](https://vmblog.com/archive/2020/08/06/kubermatic-launches-kubecarrier-to-deliver-cloud-native-service-management-at-scale-with-kubernetes-operators.aspx#.XzF64CgzY2y) August 6, 2020 via VMBlog.com ![Linux-Magazin logo](/static/linux-magazin-logo.png) ### [Kubermatic veröffentlicht Kubecarrier unter Apache-Lizenz](https://www.linux-magazin.de/news/loodse-veroeffentlicht-kubecarrier-unter-apache-lizenz/) August 6, 2020 via Linux-Magazin ![Newserector logo](/static/logo-Newserector-92288675_100254091653073_4576874522514292736_n.png) ### [Kubermatic starts the open source service hub to facilitate the complex management of services](https://www.newserector.com/kubermatic-starts-the-open-source-service-hub-to-facilitate-the-complex-management-of-services) August 5, 2020 via Newserector ![TechCrunch logo](/static/screenshot-2020-06-22-at-12.23.56-pm.png) ### [Kubermatic launches open-source service hub to enable complex service management](https://techcrunch.com/2020/08/05/kubermatic-launches-open-source-service-hub-to-enable-complex-service-management/) August 5, 2020 via TechCrunch ![SiliconANGLE logo](/static/siliconangle.jpg) ### [With newest open-source tool, Kubermatic adds a service hub to Kubernetes](https://siliconangle.com/2020/08/05/kubermatic-adds-service-hub-kubernetes-newest-open-source-tool/) August 5, 2020 via SiliconANGLE ![Container Journal logo](/static/cropped-containerjournallogostacked-1024x276.jpg) ### [Kubermatic Launches Hub for Kubernetes Operators](https://containerjournal.com/topics/container-management/kubermatic-launches-hub-for-kubernetes-operators/) August 5, 2020 via Container Journal ![Cloudcomputing Insider logo](/static/logo-1-.svg) ### [Loodse geht, Kubermatic Kubernetes Platform 2.14 kommt](https://www.cloudcomputing-insider.de/management-fuer-container-und-virtualisierung-a-940685/) June 30, 2020 via Cloudcomputing Insider ![ITOpsTimes logo](/static/ipopstimes-logo.png) ### [ITOps Times Open-Source Project of the Week: Kubermatic](https://www.itopstimes.com/contain/itops-times-open-source-project-of-the-week-kubermatic/) June 26, 2020 via ITOpsTimes ![Kubernetes Podcast from Google logo](/static/download.png) ### [Kubernetes Podcast with Kubermatic CEO Sebastian Scheele](https://kubernetespodcast.com/episode/109-kubermatic/) June 24, 2020 via Kubernetes Podcast from Google ![DevClass logo](/static/download-16-.png) ### [What’s the point: Elastic, LLVM, rebrandings, Perl, and Harbor](https://devclass.com/2020/06/24/wtp-240620-news-roundup/) June 24, 2020 via DevClass ![Linux Magazin logo](/static/linux-magazin-logo.png) ### [Kubermatic-Plattform wird Open-Source](https://www.linux-magazin.de/news/kubermatic-plattform-wird-open-source/) June 18, 2020 via Linux Magazin ![BELGIUM cloud logo](/static/belgium-cloud-inline.svg) ### [Kubermatic (voorheen Loodse) maakt Kubermatic Kubernetes-platform open source](https://belgiumcloud.com/2020/06/18/kubermatic-voorheen-loodse-maakt-kubermatic-kubernetes-platform-open-source/) June 18, 2020 via BELGIUM cloud ![heise online logo](/static/heise-online-logo.svg) ### [Cloud-native: Loodse gibt Kubermatic als Open Source frei](https://www.heise.de/news/Cloud-native-Loodse-gibt-Kubermatic-als-Open-Source-frei-4786838.html) June 17, 2020 via heise online ![vmblog.com logo](/static/vmblog.com_logo.gif) ### [Kubermatic, Formerly Loodse, Open Sources Kubermatic Kubernetes Platform](https://vmblog.com/archive/2020/06/17/kubermatic-formerly-loodse-open-sources-kubermatic-kubernetes-platform.aspx#.XvCx3kgvO3C) June 17, 2020 via vmblog.com ![LinuxAdictos logo](/static/download-23-.png) ### [Kubermatic, anteriormente Loodse, abre el código fuente de su tecnología principal](https://www.linuxadictos.com/kubermatic-anteriormente-loodse-abre-el-codigo-fuente-de-su-tecnologia-principal.html) June 17, 2020 via LinuxAdictos ![cloud7 logo](/static/ds-logo.png) ### [Kubermatic announces Kubermatic Kubernetes Platform](https://cloud7.news/cloud/kubermatic-announces-kubermatic-kubernetes-platform/) June 17, 2020 via cloud7 ![CONTAINER JOURNAL logo](/static/cropped-containerjournallogostacked-1024x276.jpg) ### [Kubermatic Open Sources Automation Platform for Kubernetes](https://containerjournal.com/topics/container-management/kubermatic-open-sources-automation-platform-for-kubernetes/) June 17, 2020 via CONTAINER JOURNAL ![siliconANGLE logo](/static/download-22-.png) ### [Kubernetes startup Kubermatic, formerly Loodse, open-sources its core technology](https://siliconangle.com/2020/06/17/kubermatic-formerly-loodse-open-sources-core-technology/) June 17, 2020 via siliconANGLE ![PR Newswire logo](/static/prn_cision_logo_desktop.png) ### [Kubermatic, Formerly Loodse, Open Sources Kubermatic Kubernetes Platform](https://www.prnewswire.com/news-releases/kubermatic-formerly-loodse-open-sources-kubermatic-kubernetes-platform-301078188.html) June 17, 2020 via PR Newswire ![THE NEW STACK logo](/static/the-new-stack-logo-1-.svg) ### [Loodse Becomes Kubermatic, an Open Source Kubernetes Provider](https://thenewstack.io/loodse-becomes-kubermatic-an-open-source-kubernetes-provider/) June 17, 2020 via THE NEW STACK ![the tech crunch logo](/static/screenshot-2020-06-22-at-12.23.56-pm.png) ### [Loodes becomes Kubermatic and open-sources Kubernetes automation platform](https://techcrunch.com/2020/06/17/loodse-becomes-kubermatic-and-open-sources-kubernetes-automation-platform/?guccounter=1&guce_referrer=aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS8&guce_referrer_sig=AQAAAH3SFinxqpdP4p8I5zaagyiPv0N6SSZ8NdYj72JDUzEJ_M7JGif8vG6WpTewucyiop6ZglCafAYfh9BHBN2MTIMhKriUA-8a1OLz00j23LJYf4T8mLOrCIWZza4tL3s2wCEPCmWneb2amDfvPxst228XYtrWskpGGSueCO0qGiFy) June 17, 2020 via the tech crunch ![THE NEW STACK logo](/static/the-new-stack-logo.svg) ### [Automating Infrastructure That Dates Back 100 Years](https://thenewstack.io/automating-infrastructure-that-dates-back-100-years/) April 16, 2020 via THE NEW STACK ![SoundCloud logo](/images/press/podcast.png) ### [Is your Kubernetes cluster a pet? Cloud Unfiltered podcast with Bill Mulligan](https://soundcloud.com/user-380516168/ep91-is-your-kubernetes-cluster-a-pet-with-bill-mulligan) February 17, 2020 via SoundCloud ![SDxCentral logo](/images/press/sdxcentral.png) ### [Kubermatic Steers Telco 5G Plans Toward Kubernetes](https://www.sdxcentral.com/articles/news/loodse-steers-telco-5g-plans-toward-kubernetes/2020/01/) January 19, 2020 via SDxCentral ![InfoQ logo](/images/press/infoq.jpg) ### [Contributing to the Kubernetes Community: Getting Started Q&A with Contributor Nikhita Raghunath](https://www.infoq.com/news/2019/08/kubernetes-nikita-raghunath/) August 30, 2019 via InfoQ ![The New Stack logo](/images/press/thenewstack.png) ### [How to Treat Your Kubernetes Clusters Like Cattle, Not Pets](https://thenewstack.io/how-to-treat-your-kubernetes-clusters-like-cattle-not-pets/) May 15, 2019 via The New Stack ![CIO logo](/static/cio.svg) ### [Kubermatic und Wingu: Von Clustern und Proximity-Plattformen](https://www.cio.de/a/loodse-und-wingu-von-clustern-und-proximity-plattformen,3576217) February 22, 2018 via CIO ![The New Stack logo](/images/press/thenewstack.png) ### [Kube-Node: Let Your Kubernetes Cluster Auto-Manage Its Nodes](https://thenewstack.io/kube-node-let-k8s-cluster-auto-manage-nodes/) November 20, 2017 via The New Stack ![t3n logo](/images/press/t3n.png) ### [Was Unternehmen beim produktiven Einsatz beachten müssen: Live gehen mit Containern](https://t3n.de/magazin/unternehmen-beim-produktiven-einsatz-beachten-muessen-242352/) July 31, 2017 via t3n ![The New Stack logo](/images/press/thenewstack.png) ### [Kubermatic Automates Kubernetes Cluster Management](https://thenewstack.io/loodse-automates-kubernetes-cluster-management/) June 5, 2017 via The New Stack ![Pressebox logo](/static/pressebox.svg) ### [German Accelerator wählt 20 deutsche Start-ups für sein Mentoring-Programm in den USA aus](https://www.pressebox.de/inaktiv/german-entrepreneurship-gmbh/German-Accelerator-waehlt-20-deutsche-Start-ups-fuer-sein-Mentoring-Programm-in-den-USA-aus/boxid/850408) May 2, 2017 via Pressebox --- ## Kubermatic Kubernetes Platform Is Now Open Source! - **URL:** https://www.kubermatic.com/blog/kubermatic-open-sources-kubermatic-kubernetes-platform/ - **Date:** 2026-05-07 - **Description:** We are excited to announce going all in on open source and making Kubermatic Kubernetes Platform publically available under the Apache 2.0 License. - **Categories:** Company - **Tags:** Announcements - **Authors:** Sebastian Scheele Today is a very special day for Kubermatic, formerly Loodse. With the [2.14 release](/blog/introducing-kubermatic-kubernetes-platform-2-14/) of **Kubermatic Kubernetes Platform**, we are excited to announce going all in on open source and making our core software **publically available under the Apache 2.0 License**. In line with our strong commitment to make Kubernetes as boring as possible, we want to empower IT teams everywhere to automate the management of hundreds or thousands of Kubernetes clusters regardless of the underlying infrastructure. As founders, we are incredibly proud of our team’s legacy of success in providing software solutions to **accelerate enterprise cloud native adoption across hybrid and multi-cloud, edge, and 5G scenarios**. In 2019, Loodse was the Top 5 corporate contributor to the Kubernetes Project right after Google, VMware, Red Hat, and Microsoft. With Kubermatic Kubernetes Platform we provide the most scalable and comprehensive Kubernetes management software solution which is widely deployed across a variety of use cases and industries. This outstanding achievement was only made possible by a team that is deeply convinced that 90% of IT time and money should be invested in writing the next generation of ground-breaking applications, not operations. With the decision to open source Kubermatic Kubernetes Platform, we felt that **Kubermatic - Kubernetes Automatic - is actually at the very heart of our company vision**: providing enterprise software solutions that fully automate Kubernetes and cloud native technologies without human intervention required. **For this reason, Loodse today becomes Kubermatic.** ### Accelerate Your Cloud Native Journey With Kubermatic Kubernetes Platform Kubermatic Kubernetes Platform automates deployment and Day2 operations of countless Kubernetes clusters across any infrastructure. It was designed and built to meet enterprise demands at scale to free up valuable resources to drive business innovation while maintaining security and control. The Open Source Kubermatic Kubernetes Platform features: * Self-healing HA Kubernetes in Kubernetes architecture based on Kubernetes CRDs and Operators for simplified management * Automated lifecycle management with built in provisioning, scaling, updating, and clean up of clusters with just an API call * Multi-tenancy and user management with preset environments for different organizational units * Identity and SSH key Management * Cluster blueprints, presets, and add-ons for governance and policy enforcement * Automated multi-cluster and multi-cloud backup handling with customizable backup locations * Infrastructure Logging & Monitoring with built in Prometheus and Grafana * Central self service portal across multi-cluster, multi-cloud, and multiple regions to deliver Kubernetes-as-a-Service within short time to market * Free choice of infrastructure stack with native support of all major cloud provider including AWS, Google Cloud Platform, and Microsoft Azure, as well as OpenStack and VMware vSphere environments * Central management of containerized and virtualized applications with native integration of KubeVirt * Containerized user cluster control plane with automated scaling of control plane components <img src="/static/Kubermatic-Kubernetes-Platform.png" alt="Scematic Illustration of Kubermatic Kubernetes Platform" width="100%"/> ### Kubermatic Kubernetes Platform is Backed by The Best *"At Packet, we are driven to empower developer-driven companies with physical infrastructure that moves at software speed. The key to turning this promise into reality is a vibrant ecosystem of software that helps our customers orchestrate and manage their workloads at any scale, globally. By open sourcing their Kubernetes Platform, the Kubermatic team is providing the community with a powerful and proven solution that is perfectly suited to the operational challenges of our hybrid multi-cloud world."* Jacob Smith, Co-founder at packet, now a part of Equinix *"Increasingly, enterprises are building on 100% open source stacks, an approach that Kinvolk has long advocated. We are therefore pleased to see Kubermatic fully open sourcing Kubermatic Kubernetes Platform, and excited to collaborate with them to enable Flatcar Container Linux as the only supported container-optimized base operating system for Kubermatic clusters."* Andrew Randall, VP Business Development at Kinvolk *"We have partnered with Kubermatic for three years to provide MetaKube, our Multi-cloud Kubernetes as a Service. It was essential we work with a team that understands Kubernetes at both a strategic and deep technical level and as a leading contributor to Kubernetes, Kubermatic has a strong footprint within the cloud native landscape. Kubermatic Kubernetes Platform has enabled us to operate Clusters for dozens of enterprise customers on Azure, AWS and our very own OpenStack cloud infrastructure. Open sourcing Kubermatic Kubernetes Platform is a great move that will help even more teams successfully benefit from cloud native infrastructure for any environment.”* Marc Korthaus, CEO at SysEleven ### Our Commitment to Our Customers While the company name changes, our focus on customers success is stronger than ever. We will continue to be at the forefront of the cloud native transformation and be a reliable partner with ever expanding software platform solutions to support our customers’ automated multi-cloud operations. This is an exciting journey for us and we look forward to embarking on it together with you. Sebastian Scheele, CEO and Co-founder Julian Hansert, COO and Co-founder ### Join Our Introductory Webinars * Join "Getting Started With Kubermatic Kubernetes Platform" on June 23 at 9 AM PST / 6 PM CEST: [Watch here](https://www.youtube.com/watch?v=1LQc4HAjBKE&t=40s) * Join "Getting Started With Kubermatic Kubernetes Platform" on June 30 at 9 AM CEST: [Watch here](https://www.youtube.com/watch?v=1D5Vd_z7wJY&t=905s) ### Learn More * Find Kubermatic Kubernetes Platform on [Github](https://github.com/Kubermatic/Kubermatic) * Check out the [Kubermatic Kubernetes Platform Documentation](https://docs.kubermatic.com/kubermatic/main/) --- ## Open Policy Agent and KubeVirt Integration in KKP 2.14 - **URL:** https://www.kubermatic.com/blog/introducing-kubermatic-kubernetes-platform-2-14/ - **Date:** 2026-05-07 - **Description:** Check the first open source release of our Kubernetes management platform - **Categories:** Products - **Tags:** KKP - **Authors:** Kristin Wittig Today, we are happy to announce the release of Kubermatic Kubernetes Platform 2.14. Kubermatic Kubernetes Platform 2.14 is the first open source release of our core cloud native platform. Significant work went into making Kubermatic Kubernetes Platform available as a community project under the Apache 2.0 Licence. This step empowers IT teams everywhere to automate the management of hundreds or thousands of Kubernetes clusters regardless of the underlying infrastructure. Enjoy:) Beyond that, here are other noteworthy highlights of Kubermatic Kubernetes Platform 2.14. ### Run Containers and VMs Side by Side with Kubermatic Virtualization With Kubermatic Virtualization powered by [KubeVirt](https://kubevirt.io/), you can now centrally deploy and manage virtual machines and containers on the same infrastructure all run by Kubernetes. Modernize your infrastructure and accelerate cloud native adoption without the need to refactor every application first. ### Extend Policies With Open Policy Agent (preview) Every organization has a defined set of policies which needs to be applied to their Kubernetes clusters. Some of these policies are mandatory to ensure your clusters meet the technical, security, and legal requirements. Other make sure your clusters follow best practices inside the organization. With the 2.14 release, Kubermatic Kubernetes Platform’s existing capability to manage policies like Network Policies or Pod Security Policies is extended with Open Policy Agent Gatekeeper.[](https://github.com/open-policy-agent/gatekeeper) [Gatekeeper](https://github.com/open-policy-agent/gatekeeper) is a validating webhook that enforces CRD-based policies executed by [Open Policy Agent](https://www.openpolicyagent.org/), a policy engine for cloud native environments hosted by the CNCF as an incubation-level project. Benefit from automated policy enforcement to ensure consistency across all your Kubernetes clusters. ### Extended OS Support With Flatcar Kubermatic Kubernetes Platform 2.14 introduces the support of [Flatcar Container Linux](https://www.flatcar-linux.org/) as a replacement of CoreOS and SUSE Linux Enterprise (SLES). Choose your preferred Operating System without investing in time-consuming upfront modifications of your standards and stack. ### More Freedom of Choice With Native Support of Alibaba Cloud Expanding the capability on which cloud infrastructure clusters can be created, Kubermatic Kubernetes Platform 2.14 adds the major hyperscale cloud provider Alibaba Cloud to its repertoire. Provision and manage your clusters on Alibaba Cloud infrastructure around the world and particularly in the Asia region. ### Run Kubernetes As You Like Kubermatic Kubernetes Platform now supports Kubernetes 1.18.To meet the highest security and reliability standards, we always run Kubermatic master components with the Kubernetes version that addresses recently discovered vulnerabilities. ### Learn More * Check out all details of the Kubermatic Kubernetes Platform 2.14 release in our [Changelog](https://github.com/kubermatic/kubermatic/blob/master/CHANGELOG.md) * Learn more about why we decided to open source Kubermatic Kubernetes Platform in our [Announcement Post](/blog/kubermatic-open-sources-kubermatic-kubernetes-platform/) --- ## Edge Computing Nirvana - The Single Pane of Glass - **URL:** https://www.kubermatic.com/blog/edge-computing-nirvana/ - **Date:** 2026-05-07 - **Description:** Edge computing with Kubernetes unifies your tech stack - **Categories:** Best Practices - **Tags:** Best Practices - **Authors:** Bill Mulligan The holy grail of IT operations is the single pane of glass that has an overview of and insight into the whole IT infrastructure. However, with each new generation of technology and the additional tooling they add to the stack, this nirvana always seems to be slipping further away rather than getting closer. As companies look to include edge computing into their technology landscape to offer new services to their customers, they must carefully consider how it will integrate into the existing infrastructure. With this move out of traditional data centers and even cloud computing, **edge computing presents a massive operational challenge with the need to effectively manage a multitude of infrastructures across a disparate set of locations**. In addition, with the necessity to run both containers and virtual machines on the edge, it begs the questions of how to seamlessly integrate all of this management together. **The Path to Edge Computing Nirvana** In working with the most successful enterprises in the world, they tell us the three main challenges they face when considering edge computing are: * Consistent infrastructure to reduce snowflake servers and deployments * Automation and self healing capabilities to reduce operational costs * Running both legacy and greenfield applications together These IT leaders know that automation and standardization in the deployment and management of applications greatly improves their talent pool and innovation rate while reducing costs. They recognize that in order to achieve their edge computing goals they need to tackle these challenges head on. However, one consistent theme is that while they all have ambitious edge computing goals, **most are stuck in the proof of concept stage or have only implemented a handful of applications**. **How Can We Make Edge Computing Operationally Feasible?** In my previous article, [Edge Computing Requires Cloud Native Thinking](https://www.kubermatic.com/blog/edge-computing-requires-cloud-native-thinking-today/), I discussed that the standardization and automation of cloud native technologies, like Kubernetes, will enable the edge. However, this still begs the question of how to manage both containers and virtual machines in one stack. This hurdle can once again be answered by cloud native ideas, all that is needed is a consistent way to manage both containers and virtual machines. **How Can We Run Virtual Machines and Containers Side by Side on the Edge?** [KubeVirt](https://kubevirt.io/) allows virtual machines to run as pods inside Kubernetes allowing containers and virtual machines to be run side by side with one infrastructure stack. This has [multiple benefits](https://www.kubermatic.com/blog/running-containers-and-virtual-machines-side-by-side/) for developers, operators, and companies even when just talking about the cloud. When this is stretched out to the edge, the benefits are even larger. When leveraging Kubernetes and KubeVirt on the edge, you finally gain the ability to run one stack whatever the workload may be using just one set of tools. **Crossing the Chasm to Edge Computing** As demonstrated above **Kubernetes offers many capabilities to handle the scale and distribution of edge computing** including the ability to run containers and virtual machines side by side. However, edge computing requires many clusters, even multiple at each location, to deal with latency and other technical requirements. Thus to achieve the single pane of glass nirvana, a multi-cluster management solution is crucial. We built the [Kubermatic Kubernetes Platform](https://www.kubermatic.com/products/kubermatic-kubernetes-platform/) to solve exactly this challenge. It provides **automated multi-cluster management across any infrastructure** providing enterprises a single pane of glass to deploy, control, and operate their edge computing environments. It also seamlessly integrates KubeVirt allowing companies to finally achieve edge computing nirvana. In addition, to help our customers cross the chasm to edge computing, we provide training and consulting in the three critical areas: * Designing an edge computing strategy and architecture * Mastering cloud native tooling, including Kubernetes and KubeVirt * Leveling up the team culture and thinking towards automated operations To accelerate the edge computing automation journey, we offer consulting accelerator and training accelerator packages. These engagements last from 11.5 to 20.5 days and our enterprise customers have shared it has shaved off on average 4-6 months of their learning curve. An example of Kubermatic’s accelerator packages are: * [Kubermatic Edge Computing Accelerator](/consulting/edge-computing/) * [Kubermatic Virtualization Accelerator Powered by KubeVirt](/consulting/virtualization-by-kubevirt/) * [Kubernetes Operator Engineering Accelerator](/consulting/kubernetes-operator-engineering/) When tapping Kubermatic in their edge computing journey, enterprises are working with one of the top cloud native automation companies in Europe and a lead contributor to the Kubernetes project in the Cloud Native Computing Foundation. Moreover, we were recently highlighted for [Kubermatic Kubernetes Platforms](https://www.kubermatic.com/products/kubermatic-kubernetes-platform/)’ role in delivering 5G edge computing capability in the [KubeCon North America Keynote](https://www.linuxfoundation.org/press/press-release/open-source-community-connects-global-5g-cloud-native-network). ___________________________________________________________________________ **Learn more about Kubermatic Kubernetes Platform and request a [Demo](https://www.kubermatic.com/demo/)** --- ## Running Containers and Virtual Machines Side by Side - **URL:** https://www.kubermatic.com/blog/running-containers-and-virtual-machines-side-by-side/ - **Date:** 2026-05-07 - **Description:** Run your legacy applications the cloud native way with KubeVirt on Kubernetes - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Bill Mulligan Cloud native and Kubernetes are two of the hottest buzz words in the IT industry today. However, the sparkle of these terms cannot cover the legacy tangle of tech hiding at the back of every enterprise datacenter or even cloud infrastructures. Greenfield deployments of containers can easily take advantage of these advances, but integrating into legacy systems can be much more difficult. **Without the ability to containerize existing applications, some IT departments feel they will never be able to tackle the modernization of their stack.** For various technological or security reasons, some applications may just not be suited to move from a virtual machine to a container. Faced with this reality, companies are forced to maintain two different stacks, one for legacy applications running on virtual machines and one for greenfield deployments in containers. This approach is unsustainable for many companies who have enough challenges maintaining one stack let alone two. **KubeVirt to the Rescue** **Cloud native infrastructure shouldn’t be seen as out of reach, but rather an enabler for IT modernization, like running virtual machines side by side with containers.** The key is understanding which technologies help facilitate the desired state. [KubeVirt](https://kubevirt.io/) is a very powerful and proven open source project that can help integrate legacy and greenfield systems and yields considerable advantages for development teams, operations, and companies as a whole. **KubeVirt technology addresses the needs of development teams that have adopted or want to adopt Kubernetes but possess existing virtual machine-based workloads that cannot be easily containerized.** More specifically, the technology provides a unified development platform where developers can build, modify, and deploy applications residing in both application containers as well as virtual machines in a common, shared environment. ![KubeVirt Architecture](/static/KubeVirt-Architecture.png) At the same time, by running virtual machines and containers the same way, operators are able to massively reduce the complexity of their stack. **Instead of having to run two separate infrastructures, they can run every application on one modern platform without the need to rewrite all of them first.** The legacy and greenfield applications benefit from being able to use the same monitoring and logging stack across them and building integrations once but deploying them everywhere. Moreover, connecting virtualized and containerized workloads is also simplified. Beyond that, policy and governance concepts can be centralized to one stack rather than having to maintain multiple ones. Finally, virtual machines running in containers benefit from the ability to self heal and live migrate workloads, reducing operational toil. At the company level, the benefits of KubeVirt become even more apparent. Being able to run virtual machines and containers on the same infrastructure allows companies to modernize in motion. This means migrating existing workloads onto modern infrastructure, deploying greenfield applications today, and serving as a crucial bridge between them. Developer velocity is increased to deploy features faster and operational processes are simplified to reduce costs. Cloud native infrastructure isn’t a future paradigm, KubeVirt makes it an enabler today to get to tomorrow. **KubeVirt on Kubermatic Kubernetes Platform** At Kubermatic, we realized the benefits KubeVirt could bring to our customers and decided to integrate it into our Kubermatic Kubernetes Platform. **With Kubermatic Virtualization powered by KubeVirt, our customers have the easiest way to manage their complete infrastructure stack.** They can automate the operations of Kubernetes clusters, virtual machines, and the containers running on them leveraging 100% open source software. We are even bringing KubeVirt to edge computing allowing our customers to run virtual machines on the edge for free. To see the benefits of KubeVirt or Kubermatic, you can check them out on [GitHub](https://github.com/kubevirt) or [request a demo](https://www.loodse.com/demo/) today. --- ## ONAP Consulting - Cloud Native Orchestration - **URL:** https://www.kubermatic.com/kubernetes/onap-consulting/ - **Date:** 2026-03-17 - **Description:** ONAP Consulting for running on Kubernetes # ONAP Consulting - Cloud Native Orchestration ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ![](/static/rancher-eol_hu_6cc7e7b21b32622c.jpg) ## Cloud Native ONAP with Kubermatic - Run ONAP on Kubernetes with KubeOne and Kubermatic Kubernetes Platform - Best practices and blue prints for running ONAP cloud native - Simplify ONAP deployment and upgrade process **Why Kubermatic:** Kubermatic is the world leading expert in Kubernetes and the cloud native telco. Rely upon our industry expertise to bring your best practice ONAP deployment into production today. - Top 5 corporate contributor to the Kubernetes project - Cloud Infrastructure Telco Taskforce Kubernetes Reference Conformance Workstream Leader - Cloud Native Open Verification Program Member ## Technology Solutions ### Kubermatic Kubernetes Platform for ONAP Designed to automate IT operations from the infrastructure to the application, Kubermatic Kubernetes Platform easily operates thousands of Kubernetes clusters with consistency from the cloud to the core datacenter to the edge. ### Kubermatic KubeOne for ONAP Designed to deploy and operate standalone Kubernetes clusters, Kubermatic KubeOne automates the lifecycle management of single clusters deployed on the edge. [See 5G Edge Solution Brief](/files/Solution-Brief_Kubermatic-for-Edge-Computing.pdf?v=20210429) Fill out the form for questions regarding migration, consulting, and support. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Let's Talk](/demo/) --- ## ONAP Training - Cloud Native Orchestration - **URL:** https://www.kubermatic.com/kubernetes/onap-training/ - **Date:** 2026-03-17 - **Description:** ONAP Training for Running on Kubernetes # ONAP Training - Learning Cloud Native Orchestration ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ![](/static/rancher-eol_hu_6cc7e7b21b32622c.jpg) ## Teaching Cloud Native ONAP with Kubernetes - Learn how to run ONAP on Kubernetes with KubeOne and Kubermatic Kubernetes Platform - Courses with best practices and blue prints for using ONAP with Kubernetes - Simplify complex ONAP deployment and upgrade process **Why Kubermatic:** Kubermatic is the world leading expert in Kubernetes and the cloud native telco. Rely upon our industry expertise to bring your best practice ONAP deployment into production today. - Top 5 corporate contributor to the Kubernetes project - Cloud Infrastructure Telco Taskforce Kubernetes Reference Conformance Workstream Leader - Cloud Native Open Verificaiton Program Member ## Technology Solutions ### Kubermatic Kubernetes Platform for ONAP Designed to automate IT operations from the infrastructure to the application, Kubermatic Kubernetes Platform easily operates thousands of Kubernetes clusters with consistency from the cloud to the core datacenter to the edge. ### Kubermatic KubeOne for ONAP Designed to deploy and operate standalone Kubernetes clusters, Kubermatic KubeOne automates the lifecycle management of single clusters deployed on the edge. [See 5G Edge Solution Brief](/files/Solution-Brief_Kubermatic-for-Edge-Computing.pdf?v=20210429) Fill out the form for questions regarding migration, consulting, and support. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Let's Talk](/demo/) --- ## Rancher 1.6 End of Life - Migrate today! - **URL:** https://www.kubermatic.com/kubernetes/rancher-end-of-life/ - **Date:** 2026-03-17 - **Description:** Rancher migration for 1.6 End of Life (EOL) # Rancher 1.6 End of Life - Migrate today! ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ![](/static/rancher-eol_hu_6cc7e7b21b32622c.jpg) ## Kubermatic Kubernetes Platform - Your Alternative to Rancher 1.6 - On June 30, 2020, the End of Life (EOL) for Rancher 1.6 will occur - Rancher Labs support portal will no longer be available beyond this date. - No straightforward upgrade path available from Rancher 1.6 to 2.x. - Rancher 2.x. has a complete new architecture **Why Kubermatic Kubernetes Platform:** Kubernetes has become the de-facto standard to drive innovation and business value in IT. Kubermatic Kubernetes Platform allows you to manage your enterprise workloads – from cloud native microservices to viable legacy applications – with one platform on any infrastructure. Kubermatic Kubernetes Platform empowers you to centrally manage the global automation of thousands of Kubernetes clusters across multicloud, on-prem and edge with unparalleled density and resilience. - HA Self-healing Infrastructure - Multi-tenancy and User Management - Multicloud Self Service Portal - 100% Vanilla Kubernetes Fill out the form for questions regarding migration, consulting and support. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Let's Talk](/demo/) --- ## Introducing Aquayman - **URL:** https://www.kubermatic.com/blog/introducing-aquayman/ - **Date:** 2026-05-07 - **Description:** A new tool to help keep your Quay.io organization's teams and robots under control. - **Categories:** Community - **Tags:** Open Source Projects - **Authors:** Christoph Mewes At Kubermatic we are using Quay.io to host our various Docker repositories. Over the last few years, cruft accumulated and we noticed that keeping team memberships up-to-date as employees and customers change became a hassle. For Github we already make use of [Peribolos](https://github.com/kubernetes/test-infra/tree/master/prow/cmd/peribolos), a wonderful tool to manage your Github organization declaratively. For quay we unfortunately did not find an equivalent solution, so we made our own. Say hello to [Aquayman](https://github.com/kubermatic-labs/aquayman) (short for "A Quay Manager"). It allows you to manage teams, memberships and robot accounts for your organization by just editing a single YAML file. To get started, it's best to download the latest release and export your current configuration (not just as a starting point, but also as a backup): ``` $ wget https://github.com/kubermatic-labs/aquayman/releases/download/v0.1.2/aquayman_0.1.2_linux_amd64.zip $ unzip aquayman_0.1.2_linux_amd64.zip aquayman # prepare your configuration file by setting the org name $ echo "organization: mytestorg" > mytestorg.yaml # use Aquayman to dump your existing configuration $ ./aquayman -config mytestorg.yaml -export 2020/05/14 13:56:55 ► Exporting organization mytestorg… 2020/05/14 13:56:55 ⇄ Exporting robots… 2020/05/14 13:56:56 ⚛ drone 2020/05/14 13:56:57 ⚛ netlify 2020/05/14 13:56:58 ⇄ Exporting repositories… 2020/05/14 13:56:59 ⚒ myapp 2020/05/14 13:56:59 ⚒ secretapp (private) 2020/05/14 13:57:00 ⇄ Exporting teams… 2020/05/14 13:57:00 ⚑ owners 2020/05/14 13:57:02 ⚑ developers 2020/05/14 13:57:03 ⚑ customers 2020/05/14 13:57:05 ✓ Export successful. ``` Your `mytestorg.yaml` will now be updated and look something like this: ```yaml organization: mytestorg teams: - name: owners role: admin members: - xrstf - name: developers role: creator members: - scheeles - kdomanski - name: customers role: creator members: - mytestorg+initech - mytestorg+omniconsumerproducts repositories: - name: myapp teams: developers: write customers: read - name: secretapp users: xrstf: write robots: - name: initech description: Personal Account for Peter Gibbons - name: omniconsumerproducts description: "Contact person: Dick Jones" ``` (The Aquayman repository contains a [documented example configuration](https://github.com/kubermatic-labs/aquayman/blob/master/config.example.yaml).) If you start with an existing, messy organization, your next step will probably be to clean up your configuration a bit. Once you are satisfied, you can apply the configuration: ``` $ ./aquayman -config mytestorg.yaml 2020/05/14 13:57:55 ► Updating organization mytestorg… 2020/05/14 13:57:55 ⇄ Syncing robots… 2020/05/14 13:57:56 + ⚛ drone 2020/05/14 13:57:57 + ⚛ netlify 2020/05/14 13:57:58 ⇄ Syncing repositories… 2020/05/14 13:57:59 ✎ ⚒ myapp 2020/05/14 13:57:59 ✎ ⚒ secretapp (private) 2020/05/14 13:58:00 ⇄ Syncing teams… 2020/05/14 13:58:00 ✎ ⚑ owners 2020/05/14 13:58:02 ✎ ⚑ developers 2020/05/14 13:58:03 ✎ ⚑ customers 2020/05/14 13:58:05 ⚠ Run again with -confirm to apply the changes above. ``` Aquayman shows you a diff-style output, hinting at the actions it would perform. If you are once again happy, you can run it again with the `-confirm` flag. ``` $ ./aquayman -config mytestorg.yaml 2020/05/14 13:58:55 ► Updating organization mytestorg… ...magic happens... 2020/05/14 13:59:05 ✓ Permissions successfully synchronized. ``` Congratulations, time to grab a coffee! At Kubermatic we manage our configuration in Github, so we get a nice review-workflow whenever permissions need to change, have an audit trail and can restrict the permissions to manage our organization even further. The less human intervention needed, the better. --- ## Kubernetes 101 Part 3: Introducing Pods - **URL:** https://www.kubermatic.com/resources/kubernetes-101-introducing-pods/ - **Date:** 2026-03-17 - **Description:** Watch our webinar and learn all that you need to know about Pods. # Introducing Pods ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Watch the Third Part of Our Webinar Series and Get More Insights on the Theoretical and Technical Fundamentals of Kubernetes and Cloud Native Technologies. In the third part of our Kubernetes 101 series we will introduce pods - the smallest entity in Kubernetes. Pods consist of one or more containers and are the central object type on top of which others build up their functionalities. Topics covered in this session: - The anatomy of a Pod - Multi-container application patterns - The declarative and the imperative way of starting Pods - Getting into the Pods details - Getting logs from and Ecec-ing into a Pod - Why you should not work with Pods ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Edge Computing Requires Cloud Native Thinking Today - **URL:** https://www.kubermatic.com/blog/edge-computing-requires-cloud-native-thinking-today/ - **Date:** 2026-05-07 - **Description:** Learn how to use automation and standarization for edge computing - **Categories:** Best Practices - **Tags:** Best Practices - **Authors:** Bill Mulligan Edge computing is creating a new internet. In an age where consumers and businesses demand the smallest possible delay between asking a question and getting an answer, edge computing is the only way to reduce the time to insight. Edge computing shrinks this gap by lowering latency, dealing with data even when there is insufficient bandwidth, decreasing costs, and handling data sovereignty and compliance. While centralized cloud computing will persist, the radically different way in which we can create and act upon data at the edge of the network will and is creating novel markets and unlocking new value. **By 2024, the edge computing market is expected to be worth over $9.0 billion with a compound annual growth rate of 30%.** However, to make these markets viable and fully unlock their potential will require taking into account the operational and business models that they require. While cloud computing has been able to rely upon centralization and economies of scale to construct the business model, edge computing needs a new paradigm. With hardware and software spread across hundreds or thousands of locations, the only feasible way to manage these distributed systems is through standardization and automation. Managing distributed computing systems is not new to IT, precursing and some would say bringing about the internet, but the scale and complexity demanded by edge computing are novel. Beyond just the sheer number of locations, edge computing must also take into account harsh environments outside traditional antiseptic datacenters, remote or unreachable locations, spotty connections, dynamic provisioning, global data experience, and security risks. Beyond these technical challenges also lie the business ones. When examining the edge as a business, it quickly becomes clear that they need to be as close to zero-touch environments as possible because every truck roll can take a massive dent out of the margins. **How can we make edge computing feasible?** While cloud native technologies were born in the cloud, the operating and business paradigms they enable will make edge computing possible. Looking at the cloud native definition, we find that standardization, like immutable infrastructure and declarative APIs, combined with robust automation create manageable systems that require minimal toil. This standardization and automation are key to making edge computing both operationally and financially viable. At the core of the cloud native ecosystem is Kubernetes. It was originally designed as a loosely coupled system with a declarative API and built-in reconciliation loops. These two features make Kubernetes perfectly suited for edge computing. First, it provides a standardized API to do the lifecycle management of hardware and software across disparate infrastructure and locations. Rather than having to redesign compute and applications for each use case or location, they can be designed once and deployed many times. This will allow businesses to easily scale around the world to meet their customers at their doorstep. Second, the reconciliation loops automate manual tasks to construct a zero touch environment with self-healing infrastructure and applications. Leveraging Kubernetes to provide standardization and automation of infrastructure and applications at the edge will allow companies to scale through software rather than people. This opens up new business models that were previously too expensive to be feasible. **The path to cloud native automation** In working with the most successful enterprises in the world, they tell us the four main challenges they face are: * Consistent infrastructure to reduce snowflake servers * Unstable products * Retaining and recruiting talent to build and maintain edge computing architectures These IT leaders know that automation in the deployment and management of applications greatly improves stability, innovation rate, and costs. They wisely recognize that going cloud native is the path to achieving their edge computing goals. One consistent theme is that they all have ambitious edge computing goals but most are stuck in the proof of concept stage or have only implemented a handful of applications. **Ambitious goals, but service providers are often stuck in POC or struggling to manage edge clusters** When stuck, these companies have not yet crossed the chasm of IT automation on the edge. Companies get stuck at the chasm for one or more of the following reasons: 1. Underestimating the complexity of edge computing 2. Not adopting the new operational models required for edge computing 3. Failing to invest in winning the hearts and minds of the existing team to retool their skillset around cloud native automation We help companies crossing this chasm, with Kubermatic Kubernetes Platform, our enterprise Kubernetes on the edge management platform. With our effort and that of our partners in the Cloud Native Computing Foundation ecosystem, we predict that the chasm will be crossed and that in the next three years, enterprises across every major vertical industry adopt edge computing. By January 2023, edge computing will become pervasive across every industry vertical. **Crossing the edge in your organization** Kubermatic is known for Kubermatic Kubernetes Platform. By demand from our enterprise clients, we also created training and consulting to support enterprises’ cloud native journey. We help companies cross the chasm of edge computing automation adoption in the three critical areas of: * Designing an edge computing strategy and architecture * Mastering cloud native tooling, including Kubernetes * Leveling up the team culture and thinking towards automated operations To accelerate the edge computing automation journey, we offer consulting accelerator and training accelerator packages. These engagements last from 2 to 11.5 days and our enterprise customers have shared it has shaved off on average 4-6 months of their learning curve. An example of Kubermatic’s accelerator packages are: * [Kubermatic Kubernetes Platform Edge Computing Accelerator](https://hubs.ly/H0qCDsh0) * [Cloud Native Accelerator for Developer](https://hubs.ly/H0qCDsh0) * [Kubernetes Accelerator for Operator](https://hubs.ly/H0qCDsh0) * [Application Migration Accelerator](https://hubs.ly/H0qCDsh0) * [Kubernetes Operator Engineering Accelerator](https://hubs.ly/H0qCDsh0) When tapping Kubermatic in their edge computing journey, enterprises are working with one of the top cloud native automation companies in Europe and a lead contributor to the Kubernetes project in the Cloud Native Computing Foundation. Moreover, we were recently highlighted for [Kubermatic Kubernetes Platform](https://hubs.ly/H0qCBF80)’s role in delivering 5G edge computing capability in the [KubeCon North America Keynote](https://www.linuxfoundation.org/press-release/2019/11/open-source-community-connects-global-5g-cloud-native-network/). At the start of this new decade, now is the time to think about your edge computing goals and where your IT organization is on the cloud native automation journey. Here are a few questions to help you: * Do you have an edge computing strategy, roadmap, and architecture in place? * Have you won the hearts and minds of your IT organization to transform their skills, mindsets, and processes? * Does your team have the technical skills for Kubernetes and other cloud native automation tools? If you surface any challenges in your plans contact us and we will help you resolve these challenges and greatly accelerate your journey to edge computing automation. ___________________________________________________________________________ **Learn more about our Kubermatic Kubernetes Platform and [request a demo](/demo/) to learn more** Kubermatic Kubernetes Platform is an enterprise software platform company that enables enterprises and service providers to deliver automated IT operations. Kubermatic Kubernetes Platform automates thousands of Kubernetes clusters across any infrastructure including the edge with unparalleled density and resilience. With Kubermatic Kubernetes Platform, developers work with the cloud native stack they prefer and have freedom of choice and a consistent experience across all environments. By automating operations, teams focus on writing the next generation of ground-breaking applications, not daily operations. --- ## Kubernetes as a Container Orchestration Tool - **URL:** https://www.kubermatic.com/blog/kubernetes-as-a-container-orchestration-tool/ - **Date:** 2026-05-07 - **Description:** Learn about basic Kubernetes concepts and get familiar with the Kubernetes background and ecosystem. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Seyi Ewegbemi **Kubernetes as a Container Orchestration Tool** In our last post [Getting Started With Containers](/blog/getting-started-with-containers/), we discussed the basic terms, concepts and tools that are associated with containers. It is time to take a step further by diving into Kubernetes as a container orchestration tool. I will explain step by step how Kubernetes works and how to deploy an application to Kubernetes. **What is Kubernetes** Kubernetes, also known as K8s, is an open-source container orchestration tool originally developed by Google Engineers for automating container application deployment, scaling, load balancing and management. Currently, Kubernetes is being maintained by the [Cloud Native Computing Foundation (CNCF)](https://www.cncf.io/). **The Background and Ecosystem** The history: “Kubernetes ([κυβερνήτης](https://en.wiktionary.org/wiki/%CE%BA%CF%85%CE%B2%CE%B5%CF%81%CE%BD%CE%AE%CF%84%CE%B7%CF%82), Greek for "[helmsman](https://en.wikipedia.org/wiki/Helmsman)" or "pilot") was founded by Joe Beda, Brendan Burns, and Craig McLuckie. They were joined by other Google engineers including Brian Grant and Tim Hockin and was first announced by Google in mid-2014. There is a significant influence on its development and design by Google's [Borg](https://en.wikipedia.org/wiki/Borg_(cluster_manager)) system, and many of the top contributors to the project previously worked on Borg. The original codename for Kubernetes within Google was Project Seven of Nine, a reference to a [Star Trek character of the same name](https://en.wikipedia.org/wiki/Seven_of_Nine) that is a "friendlier" [Borg](https://en.wikipedia.org/wiki/Borg_(Star_Trek)). The seven spokes on the wheel of the Kubernetes logo are a reference to that codename. The original Borg project was written entirely in C++, but the rewritten Kubernetes system is implemented in Go Programming Language. The first version of Kubernetes (v1.0) was released on July 21, 2015. Along with this release, Google and the [Linux Foundation](https://en.wikipedia.org/wiki/Linux_Foundation) entered into a partnership to form the[ Cloud Native Computing Foundation](https://en.wikipedia.org/wiki/Linux_Foundation#Cloud_Native_Computing_Foundation) (CNCF) and offered Kubernetes as a seed technology. On March 6, 2018, Kubernetes Project reached ninth place in commits at GitHub, and second place in authors and issues to the [Linux kernel](https://en.wikipedia.org/wiki/Linux_kernel)". **Kubernetes Ecosystem** Below is the graphical representation of the Kubernetes Ecosystem in May 2020. It is a recommended path through the cloud-native landscape and provides a comprehensive overview of cloud native technologies and projects over the entire stack, from provisioning and runtimes to orchestration, and app definition and development. Status quo, it comprises 1,390 cards with a total of 2,208,407 stars, market cap of $15.5T and funding of $65.42B. **KUBERNETES ECOSYSTEM SCHEMATICS** ![Kubernetes landscape](/static/landscape-kuber-min-1.jpg) **Kubernetes Features** Kubernetes has the following features: * Service discovery and load balancing * Self-healing * Storage orchestration * Automatic rollout and rollback * Secret and configuration management * Horizontal scaling * Batch execution * Automatic Bin packing **Kubernetes Cluster, Master and Worker Nodes** What is a Cluster? A cluster is a set of nodes grouped and managed by the master's node. One of the advantages is the ability to have access to applications through the other nodes in case one of the nodes failed. Also, the ability to share load and resources across nodes makes the cluster healthier. There are different tools available to facilitate Kubernetes cluster deployment and management including i.a. Google Container Engine for GCP, EKS for AWS or our [Kubermatic Kubernetes Platform](/products/kubermatic-kubernetes-platform/) that works for any on-prem, cloud, edge, or IoT environment. What is a Master Node? The master node is the node that controls, monitors, plans and manages worker's nodes, and also performs the administrative tasks. It uses the below components to execute the tasks effectively. ![ Kubernetes master node workflow](/static/newly-saved21.jpg) What is a Worker Node? A worker node, which can be referred to as the slave node, is the node that executes the tasks assigned by the master's node with the help of [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/). It consists of pods, containers and Kube-proxy, which is used to access the external world. ![Kubernetes worker node workflow](/static/worker-node.jpg) **Complete Workflow** ![Kubernetes worker and master node workflow](/static/pngwork23.png) **Kubernetes Declarative vs Imperative** Kubernetes can be orchestrated in two ways which can either be declarative or imperative. What does this mean? Imperative Mode: This approach which is used in development environments is the easiest and fastest way of deploying to Kubernetes using command-line. This type of approach operates on live objects and does not require configuration files but it is used on the command line passed as flags e.g. ``` kubectl run <app name>, kubectl create <app name>, kubectl delete <app name> ``` etc.\ \ Declarative Mode: This mode is in contrast to imperative mode, which entails giving step by step instructions declared in a configuration (yaml) file that is specified in a directory and use ``` kubectl apply or update <file name> ``` command to perform the deployment. This approach is used in production environments. **The Hello K8s Application** Now, it is time to put together everything we have been talking about by creating your first Kubernetes application. Follow the below steps to deploy your containerised web application. But wait…..first, we need to deploy a Kubernetes cluster. You can easily create a cluster on any environment with[ KubeOne](https://github.com/kubermatic/kubeone#getting-started). Check the [Getting Started](https://github.com/kubermatic/kubeone#getting-started) for guide and instructions. As an alternative, [Minikube](https://kubernetes.io/docs/setup/learning-environment/minikube/), Katacoda or Kubernetes playgrounds can also be used for our practising purpose. **Steps:** I assume that you already have a running Kubernetes cluster and the kubectl command-line tool. You can check your cluster by using the command: ``` $ kubectl version Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.0", GitCommit:"641856db18352033a0d96dbc99153fa3b27298e5", GitTreeState:"clean", BuildDate:"2019-03-25T15:53:57Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.0", GitCommit:"641856db18352033a0d96dbc99153fa3b27298e5", GitTreeState:"clean", BuildDate:"2019- 03-25T15:45:25Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"linux/amd64"} ``` **STEP 1:** Run nginx pod using kubectl ``` $kubectl run --image=nginx nginx-app --port=80--env="DOMAIN=cluster" ``` **STEP 2:** Expose the port ``` $kubectl expose deployment nginx-app --port=80--name=nginx-http --type=LoadBalancer ``` **STEP 3:** Check if the container is running ``` $ kubectl get pods ``` **STEP 4:** Get the external IP and port by running: ``` $ kubectl get service ``` The final output should look like the below image if everything works correctly. ``` $ kubectl get service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 37m nginx-http LoadBalancer 10.110.1.201 172.17.0.25 80:30127/TCP 52s ``` This is it: You just got started with your very first application in Kubernetes! Congratulations and welcome to the cloud native family! **Short note:** In case the external IP is in a pending state, leave it for a few minutes and run the same command again. Moreover, do not worry about some of the terms (LoadBalance, Pods, Service and deployment) used in the commands above, I will expatiate more on them as the series continues. **Introduction to Pods, Deployments and Replica sets** Next on our series are the Kubernetes resources which include pod, deployment and replicaset. We will be looking at the definition of these resources, features, functions and usage in Kubernetes. --- ## Is Your Kubernetes Cluster a Pet? - **URL:** https://www.kubermatic.com/resources/is-your-kubernetes-cluster-a-pet/ - **Date:** 2024-03-22 - **Description:** Listen and find out why and how to treat your Kubernetes clusters like cattle, not pets. # Is Your Kubernetes Cluster a Pet? ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ![](/static/resource-page_podcast_is-your-kubernetes-cluster-a-pet_hu_b7380f28e3501e35.jpg) Podcast ## Is Your Kubernetes Cluster a Pet? We all know the cattle vs. pets analogy as it applies to servers, but have you ever considered that you may be doing the same thing with your Kubernetes clusters? Bill explains why it happens, why you want to correct the situation, and how to approach it. **This podcast covers:** - Cattle vs. Pets - Cloud Native Best Practices [Listen](https://soundcloud.com/cloudunfiltered/ep91-is-your-kubernetes-cluster-a-pet-with-bill-mulligan) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Kubernetes 101 Part 2: Introducing Kubernetes - **URL:** https://www.kubermatic.com/resources/kubernetes-101-introducing-kubernetes/ - **Date:** 2022-12-01 - **Description:** Get started with Kubernetes and learn more about its architecture and features. # Introducing Kubernetes ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Watch the Second Part of Our Webinar Series and Learn More About Kubernetes, the Open Source Orchestration System That has Become the De-facto Standard for Running Cloud Native Applications. In our Kubernetes 101 series, we cover the theoretical and technical fundamentals of Kubernetes and cloud native technologies and help you get started with containers and Kubernetes. In the second part of our series we introduce Kubernetes, the open source orchestration system that has become the de-facto standard for running cloud native applications. It is the technology that will determine the cloud native future over the next decade(s). Topics covered in this session: - The background: history, competitors, the ecosystem - Kubernetes features - Master and worker Nodes - Declarative vs. imperative - The hello-k8s app - Deployments, replica sets and pods ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Infrastructure Automation Operators - **URL:** https://www.kubermatic.com/resources/infrastructure-automation-operators/ - **Date:** 2024-08-14 - **Description:** Learn about how to develop Kubernetes Operators to automate your cloud infrastructure # Cloud Infrastructure Automation Operators ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Infrastructure Automation Operators Infrastructure teams are siloed and even within the silos there are further silos. With the evolution of infrastructure as code and IaaS services, orchestration and automation of cloud infrastructure services is segmented and often isolated. Early on, we determined to look at the orchestration and management of a deployment as a set of custom resources that need to be orchestrated to deliver a set of services. This presentation will describe the service catalog we developed as a set of CRDs. We will present the architecture we leveraged to accomplish this pattern: front-end (how infrastructure is consumed) and Back-end (how infrastructure is provisioned). ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Getting Started With Containers - **URL:** https://www.kubermatic.com/blog/getting-started-with-containers/ - **Date:** 2026-05-07 - **Description:** Learn the basics about containers, Docker images, Docker commands and how to run your first Docker container. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Seyi Ewegbemi To know the nitty-gritty of Kubernetes, what it can do, and how it will get it done, it is imperative to understand some basic terms that are associated with containers and Kubernetes. In this blog post, I will start with the very basics and cover the difference between containers and VMs, the main reasons why containerization has become a thing and give an introduction into Docker and getting started running your first container. ### Why containers and not VMs? The main reason is not far-fetched. Containers eliminate compatibility issues in development, testing and production, and thereby eradicate time, financial and human resources wastage during data migration on different web services platforms. Also, containers are extremely light in weight due to the usage of a single OS to spin up the entire application as opposed to Hypervisor and multiple guest OS required in VMs. Though containers and virtual machines can both be used to get better output and productivity from every computer hardware and software, containers have some advantages over virtual machines which increases their current preferability. The advantages of containers over virtual machines are: * Memory – Use less memory (MB) as against (GB) for VMs, thus, increase speed * Portability – The portability is less cumbersome and faster * Starting time – Because of containers' lightweight, the starting time takes seconds as against minutes for VMs * Single host OS against multiple OS for VMs * VMs used Hypervisor on the hardware along with the dependencies, application and individual OS, thus, increasing the resources utilisation ### Introduction to Containers ***What is container?*** According to [Docker](https://www.docker.com/resources/what-container), “a container is a standard unit of software that packages code and all its dependencies, for the quick and secure running of applications from one computing environment to the other”. Also, containers deploy and manage microservices applications using isolated environments with their processes, network and services on the host Operating System. Using a container for shipping items at the port as an analogy: there are different types and sizes of containers for packaging various items before placing them on a container ship. The container ship then takes the containers to their various destinations irrespective of the items in the containers without any hassle. Therefore, the container ship represents a container, while the containers onboard the ship represent web applications, source codes and all its dependencies. The OS used during development in a containerised application might not be used in testing and production but will still give the same expected result. ***What makes it a toast of the moment?*** In the pre-containerisation era, when an application developed on Ubuntu is to be tested on another OS, there are high possibilities that some libraries and other services might not work the way it should due to OS disparity. Sometimes, a lot of modification is needed, which might take days, weeks or months for the application to run successfully on a different OS/platform. Thus the need for containerisation which has one of the features of allowing the testing and running of applications on any OS/platform irrespective of the OS used for the development. ### Introduction to Docker and Docker images ***What is Docker?*** Docker is an open-source tool for packaging and deploying containerised applications and its dependencies into different architecture or environments conveniently. Docker makes the efficient running of containers less cumbersome. ***What is a Docker Image?*** Docker image is a lightweight, standalone, executable package of software that includes everything needed to run a containerised application. It consists of the source codes, dependencies, runtime, system tools and libraries. A Docker image is a read-only file built from a dockerfile, or can also denote the compile version of a dockerfile. The docker image can be self-created; however, the already created ones hosted on the Docker hub repository can also be used. A docker container needs a docker image to run effectively and not vice-versa. ### Running a Docker Container Running a Docker container requires docker to be first installed on the host machine depending on your operating system. A simple guide (documentation) on how to install Docker on different operating systems can be found on <https://docs.docker.com/install/>. Once this is done, open your terminal and confirm if Docker is installed correctly by running: ``` $ docker version. ``` If everything is done correctly, the output should be the same as below. ``` $ docker version Client: Version: 18.09.7 API version: 1.39 Go version: go1.10.4 Git commit: 2d0083d Built: Wed Jul 3 13:38:22 2019 OS/Arch: linux/amd64 Experimental: false Server: Engine: Version: 18.09.7 API version: 1.39 (minimum version 1.12) Go version: go1.10.4 Git commit: 2d0083d Built: Mon Jul 1 19:31:53 2019 OS/Arch: linux/amd64 Experimental: false ``` ***Docker detached mode*** Docker can either be run in foreground or detached mode. The ***detached mode***, on the one hand, can be represented by --detached or -d flag; which means the docker container will run in the terminal background without input while ***foreground mode***, on the other hand, is the default; when ***“-d”*** is not specified. ***Running Docker container in foreground mode output:*** ``` $ docker run ubuntu Unable to find image 'ubuntu:latest' locally latest: Pulling from library/ubuntu5bed26d33875: Pull complete f11b29a9c730: Pull complete930bda195c84: Pull complete 78bf9a5ad49e: Pull complete Digest: sha256:bec5a2727be7fff3d308193cfde3491f8fba1a2ba392b7546b43a051853a341d Status: Downloaded newer image for ubuntu:latest ``` An Ubuntu ***Docker container*** can be run in a detached mode with the command: ``` $ docker run -d ubuntu ``` The above command stipulates that you are asking your system to go into the Docker Hub that was mentioned earlier, pull the latest version of an ubuntu image which is freely hosted on the Docker-hub repository and then run it on your host. Once completed, you will have a running Ubuntu Docker container on your host which can be confirmed by running: ***docker ps*** for only running containers or ***docker ps -a*** for all containers. ***Running Docker container in detached mode output:*** ``` $ docker run -d ubuntu 15f0d559f52bb6c25e733b528b4baaed4b4d2c6274eac8cbd125de3d670c144d ``` Meanwhile, if you do not want to run the latest version of the Docker container, the version can be specified using: ``` docker run -d ubuntu:18.04. docker run ubuntu:18.04. ``` The ***18.04*** is the version of the ubuntu Docker container. ### Basic Docker Commands ``` $ docker Version To check the current docker version $ docker pull <image name> To pull image from the docker hub without running $ docker run <image name> To start a container with the latest version $ docker ps To list running containers $ docker ps -a To list all containers $ docker stop<container ID> To stop a running container $ docker kill<container ID> To terminate current processes and stop the container $ docker rm <container ID> To remove a stopped container $ docker images To list the available image on the host $ docker rmi<image ID> To delete an image from the host $ docker container prune To remove all the stopped containers at once ``` More Docker commands and functionalities can be found using ***docker help*** command on the terminal. ### What is Docker Compose? Docker-compose is an automation tool for building and running multi-container Docker applications on a single host. This can be achieved by creating a docker-compose yaml file which contains the container images of the applications to be deployed. The docker-compose service can be deployed or stopped with a single command. ***Basic Docker-Compose Commands*** ``` $ docker-compose version To check the docker-compose version $ docker-compose config To verify the yaml file $ docker-compose up To deploy the applications $ docker-compose down To stop the applications $ docker-compose logs To view the logs and status ``` ### Exposing Web Applications Exposing web applications is essential because it enables two different containers on the same Docker network to communicate with each other by exposing the port. The flag EXPOSE can be used in a dockerfile or --expose on the command line. ### Container Orchestration ***What is container orchestration?*** Container orchestration is an automation process for container management and control across infrastructures. ***Features of Container Orchestration*** Container orchestration has the following features: * Scaling * Scheduling * Load balancing * Clustering * Deployment * Fault tolerance * Monitoring * Services Exposure * Networking --- ## Our Kubermatic News in April 2020 - **URL:** https://www.kubermatic.com/blog/our-loodse-news-in-april/ - **Date:** 2026-05-07 - **Description:** Our latest news on cloud platform migration projects and a virtual 4G simulation using Kubernetes and GNS3. - **Categories:** Community - **Tags:** Open Source Projects - **Authors:** Kristin Wittig Migrating onto a new platform is challenging and time consuming as it is – but can be a rewarding endeavour. Our CEO Sebastian talks in his new blog post about how Kubermatic can help.\ \ **Other highlights this month:** * Find out how to do a virtual 4G simulation using Kubernetes and GNS3 * Check out our podcast with The New Stack on how to automate infrastructure that dates back 100 years * ContainerDays 2020 will be postponed:( ### Migrating Away From NetApp Kubernetes Service NetApp recently shared that they will discontinue their NetApp Kubernetes Service. It will cease operations on April 30, 2020 giving customers and end users less than one month to migrate onto a new solution. This timeline alone could be a challenging task, but in the face of the COVID-19 pandemic it presents a monumental hurdle. [Read More](/blog/migrating-away-from-netapp-kubernetes-service/) ### Virtual 4G Simulation Using Kubernetes And GNS3 The motivation behind this blog post is to see if it is possible to simulate a 4G stack using open source tools. It covers the following: Open5gs vEPC OAI UE and eNodeB simulator, Kubernetes 1.17.3, Calico CNI, Vyos Router and GNS3. [Read More](/blog/virtual-4g-simulation-using-kubernetes-and-gns3/) ### Automating Infrastructure That Dates Back 100 Years 5G opens up many exciting business models for telcos worldwide. However, this also requires massive scaling and computing capabilities. Kubernetes, microservices and cloud native technologies are poised to be the unified base upon which large scale voice, data and media applications can be delivered. In his [The New Stack Makers](https://thenewstack.io/podcasts/makers/) Podcast, Bill Mulligan from Kubermatic explains how businesses can use Kubernetes and Kuberentes Operators to automate IT operations. [Listen](/resources/automating-infrastructure-that-dates-back-100-years/) ### ContainerDays 2020 Are Postponed Given the current situation and regulations around COVID-19, [ContainerDays](https://www.containerdays.io/) from June 22-24, 2020 cannot take place as planned. We are currently in communication with everyone involved to make sure that ContainerDays can take place some time later this year – most likely in Q4. We will keep you updated! ### Kubermatic Kubernetes Platform Edge Computing Accelerator To help you accelerate your edge computing journey, we are happy to introduce the **Kubermatic Kubernetes Platform Edge Computing Accelerator** to our portfolio. Our Kubermatic Kubernetes Platform Edge computing Accelerator is a 20.5-days engagement combining training, consultancy, and open source tooling to implement Kubernetes operations across hundreds or even thousands of distributed remote environments. If you would like to learn more please contact us at [sales@kubermatic.com](mailto:sales@kubermatic.com). --- ## Automating Infrastructure That Dates Back 100 Years - **URL:** https://www.kubermatic.com/resources/automating-infrastructure-that-dates-back-100-years/ - **Date:** 2024-03-22 - **Description:** Automating telco infrastructure with cloud native technologies # Automating Infrastructure That Dates Back 100 Years ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ![](/static/resource-page_podcast_automating-infrastrcuture_hu_52b1518d3be1f19d.jpg) Podcast ## Automating Infrastructure That Dates Back 100 Years 5G opens up many exciting business models for telcos worldwide. However, this also requires massive scaling and computing capabilities. Kubernetes, microservices and cloud native technologies are poised to be the unified base upon which large scale voice, data and media applications can be delivered. In this podcast, Bill Mulligan from Kubermatic explains how businesses can use Kubernetes and Kubernetes Operators to automate IT operations. **This podcast covers:** - Automating IT operations for telcos and enterprises - Building highly scalable cloud native platforms - The need for organisational transformation and cultural change [Listen](https://thenewstack.simplecast.com/episodes/automating-infrastructure-that-dates-back-100-years-w-bill-mulligan-of-loodse-wiiu5E8p) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Challenges in Building a Multi-cloud Kubernetes Platform - **URL:** https://www.kubermatic.com/resources/challenges-in-building-a-multi-cloud-provider-platform-with-managed-kubernetes/ - **Date:** 2026-03-17 - **Description:** Learn more about the experiences made while building the ArangoDB Managed Service offering across and GKE, AKS, or EKS. # Challenges in Building a Multi-Cloud-Provider Platform With Managed Kubernetes ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Watch Our OperatorCon Online Session Series and Create The Cloud Native Future With Kubernetes Operators Building a cloud-agnostic platform used to be a challenging task as one had to deal with a large number of different cloud APIs and service offerings. Today, as most Cloud providers are offering a managed Kubernetes solution (e.g., GKE, AKS, or EKS), it seems like developers could simply build a platform based on Kubernetes and be cloud-agnostic. While this assumption is mostly correct, there are still a number of differences and pitfalls when deploying across those managed Kubernetes solutions. This talk discusses the experiences made while building the ArangoDB Managed Service offering across and GKE, AKS, or EKS. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Migrating away from NetApp Kubernetes Service - **URL:** https://www.kubermatic.com/blog/migrating-away-from-netapp-kubernetes-service/ - **Date:** 2026-05-07 - **Description:** As a NKS customer, you have the challenge to migrate your Kubernetes clusters and workloads onto a new platform - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Sebastian Scheele NetApp recently shared that they will discontinue their NetApp Kubernetes Service (NKS) on the 19th of March. As an NKS customer, you now have the challenge to migrate your Kubernetes clusters and workloads to a new solution. NKS will cease operations on April 30, 2020 giving customers and end users less than one month to migrate onto a new solution. This timeline alone could be a challenging task, but in the face of the COVID-19 pandemic it presents a monumental hurdle. IT departments already facing reduced operational capacity now have to migrate their whole infrastructure in a minuscule timeframe. Based on the last information from public [NKS Slack](http://slack.nks.netapp.io/), there are more than [10.000 clusters ](https://app.slack.com/client/T170VMAG1/C170H4D6J)that need to be migrated today. ![Total Kubernetes clusters by provider](/static/NetApp-Kubernetes-Service.png) We are requested almost daily by our customers if we can help them migrate their Kubernetes clusters and we can help NKS customers deliver their migration in time. Kubermatic is in the [top 5 corporate contributor](/blog/loodse-is-the-top-5-corporate-contributor-to-the-kubernetes-project/) to the Kubernetes project and we are known for [Kubermatic Kubernetes Platform](/products/kubermatic-kubernetes-platform/) and [KubeOne](/products/kubermatic-kubeone/) ([Github](https://github.com/kubermatic/kubeone)). Depending on the exact use-case, we can provide two ways to manage clusters in the future with either KubeOne and/or Kubermatic Kubernetes Platform. KubeOne is an open source Kubernetes cluster lifecycle management tool that automates cluster operations on any cloud, on-prem, edge, and IoT environment with one tool that works on every platform. Kubermatic Kubernetes Platform allows operators to centrally manage the global automation of thousands of Kubernetes clusters across multicloud, on-prem, and edge with unparalleled density and resilience. Both solutions support multiple cloud providers including AWS, Azure, GCE and on-prem installation with VMware and bare metal. If you face any challenges migrating away from NetApp Kubernetes Service, we can and will help you resolve them and greatly accelerate your journey to cloud native. We offer consulting packages like “[Kubernetes Accelerator for Operator](/consulting/kubernetes-for-operators/)” or “[Application Migration Accelerator](/consulting/application-migration/)” to speed up migration to a new solution. Learn more about our Kubermatic Kubernetes Platform Enterprise Software Solution, and request a [Demo](/demo/) to learn more. --- ## Kubernetes 101 Part 1: Getting Started With Containers - **URL:** https://www.kubermatic.com/resources/k8s-101-webinar-series-part-1-getting-started-with-containers/ - **Date:** 2024-02-12 - **Description:** Watch our introductory webinar to learn how to efficiently pack software with Containers. # Getting Started With Containers ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Watch Our Introductory Webinar Series to Get Started With Kubernetes & Containers! In our Webinar Kubernetes 101 series, we cover the theoretical and technical fundamentals of these breakthrough technologies and help you get started with containers and Kubernetes. Containers are a more efficient way of packaging software – including all the elements needed to run software such as code, runtime, system tools, system libraries, and settings. Although they are more and more becoming a commodity, they form the very basis of the cloud native transformation. In the first part of our series, we’ll provide you with a recap on how to get started with containers. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Showcasing the First End-to-End 5G Cloud Native Network - **URL:** https://www.kubermatic.com/resources/open-source-communities-demonstrate-end-to-end-5g-cloud-native-network/ - **Date:** 2022-12-01 - **Description:** Learn how a diverse group of leading cloud native organizations built and showcased the first end-to-end 5G cloud native network at KubeCon San Diego. # Building An End-to-End 5G Cloud Native Network ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Solution Brief ## Leading cloud native organizations collaborate to fill gaps for 5G telecom services and use cases 5G brings with it a tremendous promise but also new requirements. Cloud native technologies can be used to meet several of these demands by providing benefits in the areas of flexibility, scalability, performance, and resilience. To prove that a 5G cloud native approach can work and to identify new requirements a diverse group of expert companies, Kubermatic among them, built and showcased the first end-to-end 5G cloud native network at KubeCon San Diego. Collaborative Development: - 80+ Volunteers - 15 Companies - 20+ Open Source Projects - 4 Month Effort [Read](/static/LFN_5G_CloudNativeSolutionBrief_022420.pdf) ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Our Kubermatic News in March - **URL:** https://www.kubermatic.com/blog/our-loodse-news-in-march/ - **Date:** 2026-05-07 - **Description:** Learn about the latest Kubermatic Kubernetes Platform 2.13 release, the OperatorCon Online Sessions and our Kubernetes 101 webinar series. - **Categories:** Community - **Tags:** Open Source Projects - **Authors:** Kristin Wittig Within the shortest time possible, Covid-19 has turned the world as we know it upside down. In times of uncertainty, we would like to assure you of our firm support: Our geographically distributed team is well equipped for remote work. We can help with remote Kubernetes / Cloud Native Training, support for Kubernetes Operations (Managed, level support, automation) and more. Let us know how we can help you stay up and running. Although all of us are all busy dealing with the new situation, we are convinced that we need to think ahead. That is why we still want to provide you with some news this month: * Proud to announce **Kubermatic Kubernetes Platform 2.13** * Guess who is the **Top 5 Corporate Contributor** to Kubernetes? * Take a look at our **NEW Resource Page** * Check out our **OperatorCon Online Sessions** * Start your cloud native journey with our **Kubernetes 101 Webinar Series** ### Announcing Kubermatic Kubernetes Platform 2.13 At Kubermatic, we are determined to create a cloud native future where 90% of IT time and money is spent on business innovation, not operations. This month, we are thrilled to announce the general availability of Kubermatic Kubernetes Platform Kubernetes Platform 2.13. The new release comes with an improved user experience with **enhanced UI features**, **dynamic Kubelet configuration** for optimized workflows all the while supporting **Red Hat Enterprise Linux** and **SUSE Linux Enterprise.** **[Read More](/blog/announcing-kubermatic-2-13-new-ui-features-and-dynamic-kubelet-configuration/)** ### Kubermatic Is The #5 Corporate Contributor To Kubernetes We are very proud of what our team has achieved in the last 12 months. Kubermatic is the **Top 5 contributor to the Kubernetes Project right after Google, VMware, Red Hat and Microsoft** and outplaying giants such as Amazon, Huawei and IBM. This speaks to the versatility, commitment and most of all ingenuity of our entire engineering team. [Take a Look](https://k8s.devstats.cncf.io/d/9/companies-table?orgId=1&var-period_name=Last%20year&var-metric=commits) ### Our New Resource Library Check out our brand new resource library to find recordings of our talks from **KubeCon to ContainerDays**, from **intros to advanced deep dives**. We also feature our webinars, including our brand new **Webinar Series Kubernetes 101** and **OperatorCon Online Sessions**. We are continuously updating the page, so be on the lookout for new features and content. [Have a Look](/resources/) ### OperatorCon Online Sessions Kubernetes Operators are about to bring Kubernetes to the next level of automation. Unfortunately, our KubeCon Europe Day Zero Conference needed to be postponed as well. To still share knowledge and encourage learning in the meantime, we have decided to start the **OperatorCon Online Sessions** where the planned topics of OperatorCon will be presented virtually.\ \ Join us for our first session:\ \ April 7, 5 PM CEST\ **Challenges in Building a Multi-Cloud-Provider Platform With Managed Kubernetes**\ Jörg Schad, Arango DB [Register Here](https://www.operatorcon.io/) ### Kubernetes 101 Webinar Series Kubernetes is the choice solution for companies looking to go cloud native while **decreasing cost and optimizing the use of constrained resources**. Getting started using Kubernetes is, however, not without its pitfalls. That is why we're launching an introductory webinar series about Kubernetes and containers: **Kubernetes 101 webinars**. The webinars will cover everything from container orchestration & Kubernetes fundamentals, to replica sets and deployments as well as exposing apps.\ \ Join us for our next session:\ \ April 28, 5 PM CEST\ **Kubernetes 101 – Introduction to K8s**\ Hubert Ströbitzer, Kubermatic [Watch Here ](https://www.youtube.com/watch?v=Vu8KrUY6sXc&t=5s) --- ## Kubernetes Project: Kubermatic Is the Top 5 Contributor - **URL:** https://www.kubermatic.com/blog/loodse-is-the-top-5-corporate-contributor-to-the-kubernetes-project/ - **Date:** 2026-05-07 - **Description:** In 2019, Kubermatic is the Top 5 contributor to Kubernetes right after Google, VMware, Red Hat and Microsoft. This is an outstanding achievement. - **Categories:** Company - **Tags:** Announcements - **Authors:** Sebastian Scheele As co-founder of one of the leading Kubernetes based product companies, I am proud of what our team has achieved in the last [12 months](https://k8s.devstats.cncf.io/d/9/companies-table?orgId=1&var-period_name=Last%20year&var-metric=commits). Kubermatic is the Top 5 corporate contributor to the Kubernetes Project right after Google, VMware, Red Hat and Microsoft. This is an outstanding achievement. Founded in 2016, we are a self funded enterprise software platform startup that has grown organically since Day 1 with open source technology at our core. We play a seriously outsized role as contributor to Kubernetes and influencer in the larger Cloud Native ecosystem. Kubermatic has approximately 60 employees and our ranking is even more impressive when comparing our size to the Top 4 companies which are Google, VMware, RedHat and Microsoft. If you look at it as a percentage basis of staff, we have many times more contributors to the Kubernetes ecosystem than the preceding companies’ cloud and Kubernetes focused developer departments. Not to mention that companies like IBM, Huawei and Intel are behind us in rank and there aren’t any other startups like Rancher or Mirantis anywhere near the Top 10. ![2019 Kubernetes companies statistics by commits](/static/blog-top-5t-committer-to-the-kubernetes-project.png) But if you know Kubermatic, you are not surprised. Our clear vision for how Kubernetes can evolve to provide enterprises a comprehensive automation platform to manage all of their IT – from services to applications to infrastructure – is why we started the company and is what drives us each day. Kubermatic has been a member of the cloud native ecosystem from its very beginning. We run some of the longest standing Kubernetes Meetups in Europe, including those in Munich, Amsterdam and Hamburg. In addition to having so many contributors to upstream Kubernetes, we were very proud to have Nikhita Raghunath elected to the [Kubernetes Steering Committee](https://github.com/kubernetes/steering) last autumn. We’ve been a member of Cloud Native Computing Foundation for more than three years, exhibited at KubeCon for the same time frame, and are the host of [OperatorCon](https://www.operatorcon.io/) at the recently postponed KubeCon Europe. **Why We Invest In Open Source** At Kubermatic, we believe that open source communities develop better software to the benefit of all. Kubernetes has entered the commercialization stage of an open source project lifecycle and we are seeing companies shifting a large portion of their engineering investment from open source core contributions to proprietary contributions. However, much remains to be done in upstream Kubernetes to help enterprises achieve the ROI needed in this much hyped technology. Our vision for Kubernetes does not stop with what we currently see upstream today. We will continue actively contributing to upstream Kubernetes, cloud native technologies, and other projects that facilitate the adoption of automated multi-cloud operations. In addition to the Kubermatic sponsored open source Kubermatic Kubernetes Platform KubeOne, which automates cluster operations on your chosen cloud, on-prem, or edge environment, we have other complementary open source projects in the works that help fulfill our vision. To learn more, check out our[ community page](/company/community/) and join our projects on Github: * [Kubermatic Kubernetes Platform KubeOne](https://github.com/kubermatic/kubeone) * [Machine Controller](https://github.com/kubermatic/machine-controller) * [KubeCarrier](https://github.com/kubermatic/kubecarrier) To check out our products and learn why enterprise leaders such as Alliance, Bosch, 1&1 and many more go cloud native with Kubermatic Kubernetes Platform offerings, please see: * [Kubermatic Kubernetes Platform](/products/kubermatic-kubernetes-platform/): Automated multi-cloud Kubernetes for enterprise demands * [Kubermatic Kubernetes Platform KubeOne](/products/kubermatic-kubeone/): Your single Kubernetes Cluster Solution with enterprise support * [Kubermatic Professional Service:](/services/) Training and consultancy for your successful cloud native journey --- ## Announcing Kubermatic Kubernetes Platform 2.13 - **URL:** https://www.kubermatic.com/blog/announcing-kubermatic-2-13-new-ui-features-and-dynamic-kubelet-configuration/ - **Date:** 2026-05-07 - **Description:** The latest Kubermatic Kubernetes Platform 2.13 release comes with improved user experience and Dynamic Kubelet Configuration. - **Categories:** Products - **Tags:** KKP - **Authors:** Kristin Wittig At Kubermatic, we are determined to create a cloud native future where 90% of IT time and money is spent on business innovation, not operations. To provide you with everything you need to automate the management of countless Kubernetes clusters across any infrastructure, we are constantly working on improving Kubermatic Kubernetes Platform. Today, we are thrilled to announce the general availability of Kubermatic Kubernetes Platform 2.13. Here is an overview of the highlights of the release. **Improve User Experience With Enhanced UI Features** * Kubermatic Kubernetes Platform now incorporates the ability to **manage user permissions** on cluster resources based on roles via the UI. Roles can be defined within a namespace or cluster-wide. * Kubermatic Kubernetes Platform provides a wide selection of default and customizable **add-ons** to extend the functionality of Kubernetes. With the latest release, all customizable add-ons can be deployed in user clusters on user demand via the UI. Default add-ons are automatically deployed to each user cluster. * Kubermatic Kubernetes Platform Dashboard is now even more deeply integrated with the **Kubernetes Dashboard**. With the 2.13 release, users can open the Kubernetes Dashboard with the click of the *Connect* button. Moreover, Kubermatic Kubernetes Platform platform administrators can manage access to the Kubernetes Dashboard via Global Settings. **Improve Your Workflows With Dynamic Kubelet Configuration** * Kubermatic Kubernetes Platform 2.13 introduces the experimental **[Dynamic Kubelet Configuration](https://kubernetes.io/blog/2018/07/11/dynamic-kubelet-configuration/)** feature for chosen Machine Deployments. Dynamic Kubelet Configuration allows live reconfiguration of nodes with non-standard requirements, while leaving your other workloads’ settings intact. **Don’t Compromise On Enterprise Standards** * With the latest release, Kubermatic Kubernetes Platform provides native support for **Red Hat Enterprise Linux** and **SUSE Linux Enterprise**. This empowers enterprise users to accelerate their cloud native journey without compromising on existing enterprise policies or investing in time-consuming upfront modifications of their standards and stack. **Run Kubernetes As You Like** * Kubermatic Kubernetes Platform 2.13 supports **Kubernetes 1.17**. To meet the highest security and reliability standards, we always run Kubermatic Kubernetes Platform master components with the Kubernetes version that addresses recently discovered vulnerabilities. To receive our Kubernetes Security Updates, please sign up for our [Security Newsletter](/company/newsletter/). **Learn More** For more information on all changes, please take a look at the [2.13 Changelog](https://github.com/kubermatic/kubermatic/blob/master/CHANGELOG.md). --- ## Life of a Container - **URL:** https://www.kubermatic.com/blog/life-of-a-container/ - **Date:** 2026-05-07 - **Description:** What is a container? Are containers just a lighter form of Virtual Machines? Learn more in this blog post. - **Categories:** Community - **Tags:** Open Source Projects - **Authors:** Indradhanush Gupta **Disclaimer:** I gave a talk of the same title at [Kubernetes Forum Delhi](https://events.linuxfoundation.org/kubernetes-forum-delhi/). You may [watch the video](https://www.youtube.com/watch?v=mGWWTP1Jeso&list=PLytD1l2uNPnyMCJltPr7g4ppn9XxZi-i7&index=2&t=0s) on YouTube if you prefer that. Additionally this post also serves as a reference for the commands used in the demos. I have been programming for almost six years now and have used containers for nearly the entirety of that time. Being a programmer, curiosity got the better of me and I started asking myself the question: what is a container? One of the answers were along the lines of the following: “Oh they’re like virtual machines but only that they do not have their own kernel and share the host’s kernel.” This led me to believe for a long time that containers are a lighter form of virtual machines. And they felt like magic to me. Only when I started digging into the internals of a container I realized that this quote felt very true: > Any sufficiently advanced technology is indistinguishable from magic. > > — Sir Arthur Charles Clarke, author of 2001: A Space Odyssey And I have always tried to find a way of explaining things that look like the following at first or second glance: ![complicated-arrow](/static/complicated-arrow.png) And see if they can be explained in a much easier way: ![simple-arrow](/static/simple-arrow.png) And the first thing I learned is that, there is really no such things as a container at all. And I found that what we know as a container, is made up of two Linux primitives: 1. Namespaces 2. Control groups (cgroups) Before we look into what they are and how they help form the abstraction known as a container, it is important to understand how new processes are created and managed in Linux. Let us take a look at the following diagram: ![fork-schema](/static/fork-schema.png) In the above diagram, the parent process can be thought of as an active shell session, and the child process can be thought of as any command being run in the shell, for eg: ls, pwd. Now, when a new command is run, a new process is created. This is done by the parent process by making a call to the function `fork`. While it creates a new and independent process, it returns the process ID (PID) of the child process to the parent process that invoked the function `fork`. And in time, both the parent and the child can continue to execute their tasks and terminate. The child PID is important for the parent to keep track of the newly created process. We will come back to this later in this blog post. If you’re interested to go deeper into the semantics of `fork`, I wrote a more detailed blog post in the past describing this and how to do that with code. ## Namespaces So now that you have an idea about how new processes are created in Linux, let us try and understand what namespaces help us achieve. Namespaces are an isolation primitive that helps us to isolate various types of resources. In Linux, it is possible to do this for seven different type of resources at the moment. They are, in no specific order: * Network namespace * Mount * UTS or Hostname namespace * Process ID or PID namespace * Inter process communication or IPC namespace * cgroup namespace * User namespace I won’t go into detail about what each of them does in this post, as there is already a lot of literature on that and the man pages are possibly the best resource for them. Instead, I will try to explain network namespaces in this post and see how it helps us to isolate network resources. But before that, it is important to note that by default each of these namespaces already exists in the system and are called the host namespaces or the default namespaces. For example, the default network namespace in a system contains network interface cards for WIFI and / or the ethernet port if there’s one. All the infromation about a process is contained under `procfs`, which is typifcally mounted on `/proc`. Running `echo $$` will give us the PID of the currently running process: ``` $ echo $$ 448884 ``` And if we look inside `/proc/<PID>/ns` we will the list of namespaces used by that process. For example: ``` $ ls /proc/448884/ns -lh total 0 lrwxrwxrwx 1 root root 0 Feb 23 19:00 cgroup -> 'cgroup:[4026531835]' lrwxrwxrwx 1 root root 0 Feb 23 19:00 ipc -> 'ipc:[4026531839]' lrwxrwxrwx 1 root root 0 Feb 23 19:00 mnt -> 'mnt:[4026531840]' lrwxrwxrwx 1 root root 0 Feb 23 19:00 net -> 'net:[4026532008]' lrwxrwxrwx 1 root root 0 Feb 23 19:00 pid -> 'pid:[4026531836]' lrwxrwxrwx 1 root root 0 Feb 23 19:00 pid_for_children -> 'pid:[4026531836]' lrwxrwxrwx 1 root root 0 Feb 23 19:00 user -> 'user:[4026531837]' lrwxrwxrwx 1 root root 0 Feb 23 19:00 uts -> 'uts:[4026531838]' ``` For each namespace, there is a file which is a symbolic link\[1] to ID of the namespace. So for the network namespace, the ID of the namespace in the above example is `net:[4026532008]` while `4026532008` is the inode number. For two processes in the same namespace, this number is the same. On Linux, to create a new namespace, we can use the system call `unshare`. And to create a new network namespace we need to add the flag `-n`. So in a shell session with root privileges, we will do: ``` # unshare -n ``` We can look into the `/proc/<PID>/ns` directory to verify that we have indeed created a new namespace: ``` # ls -l /proc/$$/ns/net lrwxrwxrwx 1 root root 0 Feb 23 18:46 /proc/447612/ns/net -> 'net:[4026533490]' ``` The namespace ID is different than what we see above for the host network namespace. And running the command `ip link` after this will only show us the loopback interface: ``` # ip link 1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 ``` If there are any network interfaces like the WIFI card or the ethernet port, they won’t show up at all. In fact, if we tried to run `ping 127.0.0.1`, something we mostly take for granted to work won’t work either: ``` # ping 127.0.0.1 ping: connect: Network is unreachable ``` But why did the above happen? Let us try to understand that. At first we created a new network namespace. The very act isolated the network resources already in the default namespace. And the only interface available to us in this new namespace is the `loopback` interface. However, it does not have an IP address assigned to it yet, as a result of which `ping 127.0.0.1` does not quite work. This can be verified by running: ``` # ip address 1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 ``` Which shows that not only does this interface does not have an IP address at the moment, its `state` is also set to `DOWN`. Running the following commands would fix that: ``` # ip address add dev lo local 127.0.0.1/8 # ip link set lo up ``` At first we assigned the IP address `127.0.0.1` to that interface and set the state of the interface to `UP`and thus making it available to listen for incoming network packets. And now `ping` would work as expected: ``` # ping 127.0.0.1 PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.020 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.060 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.071 ms ``` To understand the concept of isolation, we will go forward with trying to get this new network interface (let’s call it CHILD) to talk to the host network namespace and vice versa. To aid our understanding, we will set the `PS1` variable in this shell to something easily identifiable: ``` # export PS1="[netns: CHILD]# " [netns: CHILD]# ``` And we will also spawn a new terminal with root access so that the shell running in it belongs to the host network namespace. Once again we will set the`PS1`variable to help with identifying the host namespace easily: ``` # export PS1="[netns: HOST]# " [netns: HOST]# ``` Running the `ip link` command on this interface would show the currently installed network interfaces in the system. For example: ``` [netns: HOST]# ip link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 3: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000 link/ether 0e:94:18:de:da:b3 brd ff:ff:ff:ff:ff:ff 4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default link/ether 02:42:ad:0f:83:cc brd ff:ff:ff:ff:ff:ff 11: wlp61s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DORMANT group default qlen 1000 link/ether fa:3d:a9:90:95:5d brd ff:ff:ff:ff:ff:ff ``` To list all the network namespaces in the system we can run: ``` [netns: HOST]# ip netns list ``` But that will produce an empty output if readers have been following along. So does that mean the command didn’t work or we did something wrong there, even though we created a new network namespace earlier? The answer to both of the questions is a no. As everything is a file in UNIX\[2], the `ip` command looks for network namespaces in the directory `/var/run/netns`. And currently that directory is empty. So we will first create an empty file and then try running that command again: ``` [netns: HOST]# touch /var/run/netns/child [netns: HOST]# ip netns list Error: Peer netns reference is invalid. Error: Peer netns reference is invalid. child ``` We do see the`child`namespace in the list, but we also see an error. This exists because we have not yet mapped the shell running the new namespace to this file yet. To do that, we will bind mount the `/proc/<PID>/ns/net` file to the new file we created above. This can be done by executing the following in the shell running the child network namespace: ``` [netns: CHILD]# mount -o bind /proc/$$/ns/net /var/run/netns/child [netns: CHILD]# ip netns list child ``` And this time the command to list the network namespaces works without any errors. This means that we have associated the namespace with the ID `4026533490` to the file at `/var/run/netns/child` and the namespace is now persistent. Now we need to find a way to get the host and the child network namespace to talk to each other. To do this, we will create a pair of virtual ethernet devices in the host network namespace: ``` [netns: HOST]# ip link add veth0 type veth peer name veth1 ``` In this command we create a virtual ethernet device named`veth0`while the other end of this pair device is called `veth1`. We can verify this by running: ``` [netns: HOST]# ip link | grep veth 35: veth1@veth0: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 36: veth0@veth1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 ``` At the moment, both of these devices exist in the host namespace. If we run`ip link`in the child network namespace, it will only show the `loopback` address as was the case previously: ``` [netns: CHILD]# ip link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 ``` So what can we do to make one of the veth devices show up in the child namespace? To do that, we will run the following command in the host network namespace. Because that is where the veth devices currently exist: ``` [netns: HOST]# ip link set veth1 netns child ``` Here we are instructing the`veth1`network device to be assigned to the namespace`child`. Looking at`ip link` in this namespace will not show the `veth1` device any longer: ``` [netns: HOST]# ip link | grep veth 36: veth0@if35: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 ``` While on the other hand, `veth1` now appears in the child network namespace: ``` [netns: CHILD]# ip link | grep veth 35: veth1@if36: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 ``` We have two more steps before we can make them talk to each other, which are to assign an IP address to each `veth`device and to set the state to up. So let’s do that quickly: ``` [netns: HOST]# ip address add dev veth0 local 10.16.8.1/24 [netns: HOST]# ip link set veth0 up ``` We can verify the results of the commands with: ``` [netns: HOST]# ip address | grep veth -A 5 36: veth0@if35: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN group default qlen 1000 link/ether 32:c7:79:c7:e2:e0 brd ff:ff:ff:ff:ff:ff link-netns child inet 10.16.8.1/24 scope global veth0 valid_lft forever preferred_lft forever ``` And the same for the child namespace: ``` [netns: CHILD]# ip address add dev veth1 local 10.16.8.2/24 [netns: CHILD]# ip link set veth1 up ``` ``` [netns: CHILD]# ip address | grep veth -A 5 35: veth1@if36: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 5a:62:dd:40:a6:f1 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 10.16.8.2/24 scope global veth1 valid_lft forever preferred_lft forever inet6 fe80::5862:ddff:fe40:a6f1/64 scope link valid_lft forever preferred_lft forever ``` Finally, we should be able to ping each other: ``` [netns: HOST]# ping 10.16.8.2 PING 10.16.8.2 (10.16.8.2) 56(84) bytes of data. 64 bytes from 10.16.8.2: icmp_seq=1 ttl=64 time=0.086 ms 64 bytes from 10.16.8.2: icmp_seq=2 ttl=64 time=0.099 ms 64 bytes from 10.16.8.2: icmp_seq=3 ttl=64 time=0.100 ms ``` ``` [netns: CHILD]# ping 10.16.8.1 PING 10.16.8.1 (10.16.8.1) 56(84) bytes of data. 64 bytes from 10.16.8.1: icmp_seq=1 ttl=64 time=0.057 ms 64 bytes from 10.16.8.1: icmp_seq=2 ttl=64 time=0.090 ms 64 bytes from 10.16.8.1: icmp_seq=3 ttl=64 time=0.118 ms ``` Voila! We did it! I hope that helps with understanding namespaces better. What we did above can be best described by an image of two children talking to each other with a string telephone made up of tin cans and a long string. The children can be thought of as the namespaces, while the tin cans are analogous to the virtual ethernet devices we created and used for sending and receiving network traffic. ## cgroups Next up is cgroups. They help us in controlling the **amount** of the resources that a process can consume. The best examples for this are CPU and memory. And the best use case to do this is to avoid a process from accidentally using all the available CPU or memory and choking the entire system. The cgroups reside under the `/sys/fs/cgroup` directory. Let us take a look at the contents: ``` # ls /sys/fs/cgroup/ -lh total 0 dr-xr-xr-x 5 root root 0 Feb 17 01:05 blkio lrwxrwxrwx 1 root root 11 Feb 17 01:05 cpu -> cpu,cpuacct lrwxrwxrwx 1 root root 11 Feb 17 01:05 cpuacct -> cpu,cpuacct dr-xr-xr-x 5 root root 0 Feb 17 01:05 cpu,cpuacct dr-xr-xr-x 2 root root 0 Feb 17 01:05 cpuset dr-xr-xr-x 5 root root 0 Feb 17 01:05 devices dr-xr-xr-x 2 root root 0 Feb 17 01:05 freezer dr-xr-xr-x 2 root root 0 Feb 17 01:05 hugetlb dr-xr-xr-x 9 root root 0 Feb 20 00:24 memory lrwxrwxrwx 1 root root 16 Feb 17 01:05 net_cls -> net_cls,net_prio dr-xr-xr-x 2 root root 0 Feb 17 01:05 net_cls,net_prio lrwxrwxrwx 1 root root 16 Feb 17 01:05 net_prio -> net_cls,net_prio dr-xr-xr-x 2 root root 0 Feb 17 01:05 perf_event dr-xr-xr-x 5 root root 0 Feb 17 01:05 pids dr-xr-xr-x 2 root root 0 Feb 17 01:05 rdma dr-xr-xr-x 5 root root 0 Feb 17 01:05 systemd dr-xr-xr-x 5 root root 0 Feb 17 01:06 unified ``` Each directory is a resource whose usage can be controlled. To create a new `cgroup`, we need to create a new directory inside one of these resources. For example, if we intended to create a new `cgroup` to control memory usage, we would create a new directory (the name is upto us) under the `/sys/fs/cgroups/memory` path. So let’s do that: ``` # mkdir /sys/fs/cgroup/memory/child ``` And let us take a look inside this directory. If you’re thinking: "why bother because we just created the directory and it should be empty", read on: ``` # ls -lh /sys/fs/cgroup/memory/demo/ total 0 -rw-r--r-- 1 root root 0 Feb 24 12:29 cgroup.clone_children --w--w--w- 1 root root 0 Feb 24 12:29 cgroup.event_control -rw-r--r-- 1 root root 0 Feb 24 12:29 cgroup.procs -rw-r--r-- 1 root root 0 Feb 24 12:29 memory.failcnt --w------- 1 root root 0 Feb 24 12:29 memory.force_empty -rw-r--r-- 1 root root 0 Feb 24 12:29 memory.kmem.failcnt -rw-r--r-- 1 root root 0 Feb 24 12:29 memory.kmem.limit_in_bytes -rw-r--r-- 1 root root 0 Feb 24 12:29 memory.kmem.max_usage_in_bytes -r--r--r-- 1 root root 0 Feb 24 12:29 memory.kmem.slabinfo -rw-r--r-- 1 root root 0 Feb 24 12:29 memory.kmem.tcp.failcnt -rw-r--r-- 1 root root 0 Feb 24 12:29 memory.kmem.tcp.limit_in_bytes -rw-r--r-- 1 root root 0 Feb 24 12:29 memory.kmem.tcp.max_usage_in_bytes -r--r--r-- 1 root root 0 Feb 24 12:29 memory.kmem.tcp.usage_in_bytes -r--r--r-- 1 root root 0 Feb 24 12:29 memory.kmem.usage_in_bytes -rw-r--r-- 1 root root 0 Feb 24 12:29 memory.limit_in_bytes -rw-r--r-- 1 root root 0 Feb 24 12:29 memory.max_usage_in_bytes -rw-r--r-- 1 root root 0 Feb 24 12:29 memory.memsw.failcnt -rw-r--r-- 1 root root 0 Feb 24 12:29 memory.memsw.limit_in_bytes -rw-r--r-- 1 root root 0 Feb 24 12:29 memory.memsw.max_usage_in_bytes -r--r--r-- 1 root root 0 Feb 24 12:29 memory.memsw.usage_in_bytes -rw-r--r-- 1 root root 0 Feb 24 12:29 memory.move_charge_at_immigrate -r--r--r-- 1 root root 0 Feb 24 12:29 memory.numa_stat -rw-r--r-- 1 root root 0 Feb 24 12:29 memory.oom_control ---------- 1 root root 0 Feb 24 12:29 memory.pressure_level -rw-r--r-- 1 root root 0 Feb 24 12:29 memory.soft_limit_in_bytes -r--r--r-- 1 root root 0 Feb 24 12:29 memory.stat -rw-r--r-- 1 root root 0 Feb 24 12:29 memory.swappiness -r--r--r-- 1 root root 0 Feb 24 12:29 memory.usage_in_bytes -rw-r--r-- 1 root root 0 Feb 24 12:29 memory.use_hierarchy -rw-r--r-- 1 root root 0 Feb 24 12:29 notify_on_release -rw-r--r-- 1 root root 0 Feb 24 12:29 tasks ``` Turns out operating system creates a whole bunch of files for every new directory. Let us take a look at one of the files: ``` # cat /sys/fs/cgroup/memory/demo/memory.limit_in_bytes 9223372036854771712 ``` The value in this file dictates the maximum memory that a process can use if it is part of this cgroup. Let us set this value to a much smaller number, say 4MB, but in bytes: ``` # echo 4000000 > /sys/fs/cgroup/memory/demo/memory.limit_in_bytes ``` And let us look inside this file: ``` # cat /sys/fs/cgroup/memory/demo/memory.limit_in_bytes 3997696 ``` While this is not exactly what we wrote into the file, it is approximately 3.99 MB. My guess is that this has something to do with memory alignment which is managed by the operating system. I haven’t researched this futher at the moment. (If you know the answer, please let me know!) Now let us start a new process in a new hostname namespace: ``` # unshare -u ``` This starts a new shell process. Let us try to run a command, like `wget`, which I know needs more than 4MB memory to function: ``` # wget wikipedia.org URL transformed to HTTPS due to an HSTS policy --2020-02-24 12:36:58-- https://wikipedia.org/ Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt' Resolving wikipedia.org (wikipedia.org)... 103.102.166.224, 2001:df2:e500:ed1a::1 Connecting to wikipedia.org (wikipedia.org)|103.102.166.224|:443... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: https://www.wikipedia.org/ [following] --2020-02-24 12:36:58-- https://www.wikipedia.org/ Resolving www.wikipedia.org (www.wikipedia.org)... 103.102.166.224, 2001:df2:e500:ed1a::1 Connecting to www.wikipedia.org (www.wikipedia.org)|103.102.166.224|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 76776 (75K) [text/html] Saving to: ‘index.html’ index.html 100%[============================================>] 74.98K 362KB/s in 0.2s 2020-02-24 12:36:59 (362 KB/s) - ‘index.html’ saved [76776/76776] ``` Now we noticed that the command worked. That is because this process is part of the default cgroup. To make it part of the new cgroup, we need to write the PID of this process to the `cgroup.procs` file: ``` # echo $$ > /sys/fs/cgroup/memory/demo/cgroup.procs ``` And let us look inside the contents of this file: ``` # cat /sys/fs/cgroup/memory/demo/cgroup.procs 468401 468464 ``` There seem to be two entries here. The first entry is the PID of the shell process that we wrote to the file. The other is the PID of the `cat` process that we run. This is because all child processes are part of the same cgroup as the parent by default. And once the process terminates, the PID is automatically removed from the file. If we run the same command again, we will still find two entries, but the second one would be different: ``` # cat /sys/fs/cgroup/memory/demo/cgroup.procs 468401 468464 ``` And now let us try to run the `wget` command once again: ``` # wget wikipedia.org URL transformed to HTTPS due to an HSTS policy --2020-02-24 12:44:26-- https://wikipedia.org/ Killed ``` The process gets killed immediately because it was trying to use more memory than the cgroup it is part of currently permits. Pretty neat I’d say. ## Addendum So while `namespaces` and `cgroups` allow to isolate and control the usage of resources and form the core of the abstraction, popularly known as containers, there are two more concepts that are used for enhancing the isolation further: 1. Capabilities: It limits the use of root privileges. Sometimes we need to run processes that need elevated permissions to do one thing but running it as root is a security risk because then the process can do pretty much anything with the system. To limit this, capabilities provide a way of assigning special privileges without giving system wide root privileges to a process. One example is if we need a program to be able to manage network interfaces and related operations, we can grant the program the capability `CAP_NET_ADMIN`. 2. Seccomp: It limits the use of syscalls. To ramp down on security even further, it is possible to use them to block syscalls that can cause additional harm. For example blocking `kill` syscall will prevent the processes from being able to terminate or send signals to other processes. ## Recap So while`namespaces`allow us to isolate the **type** of resource,`cgroups`help us to control the **amount** of resource usage by a process. And `capabilities` limit the use of root privileges by breaking down operations into different types of capabilities. Finally `seccomp` helps to block processes from invoking unwanted syscalls. These concepts combined together form a container, which is a nicer abstraction than having to worry about all of these at the same time. ## One final note The diagram about`fork`earlier in this post is slightly incomplete. Here is a more complete diagram: ![form-waitpid](/static/fork-waitpid.png) As noted earlier `fork` returns the child’s PID to the parent process, and it uses this PID to “wait” for the child process to finish execution. This is done by the `waitpid` syscall. This is important to avoid zombie processes and is known as reaping. Once a child process has terminated, it is the responsibility of the parent to ensure any resources allocated for the child process are cleaned up. In a nutshell, **this** is the job of a container runtime or a container engine. It spawns new conatiners or child processes and ensures the resources are cleaned up once the container has terminated. ## References * I found a lot of information about `namespaces` in this amazing seven part series on lwn.net: https://lwn.net/Articles/531114/. * Julia Evans’ post on What even is a container is a brilliant guide for grasping the concepts quickly: https://jvns.ca/blog/2016/10/10/what-even-is-a-container/ * man pages for `namespaces`, `unshare` and `cgroups` have been very helpful as well and is a recommended reading. That is all for now. I hope this post was helpful and containers don’t feel like magic anymore. \ Footnotes:\ \[1]: Quoting the man page for `namespaces`: “In Linux 3.7 and earlier, these files were visible as hard links. Since Linux 3.8, they appear as symbolic links.”\ \[2]: https://en.wikipedia.org/wiki/Everything_is_a_file --- ## Kubernetes Forum Bengaluru 20: Auditing in Kubernetes - **URL:** https://www.kubermatic.com/resources/kubernetes-forum-bengaluru-2020-talk-nikhita-raghunath-auditing-in-kubernetes-101/ - **Date:** 2026-03-17 - **Description:** Learn how to stay informed about what goes on in your Kubernetes cluster. # Kubernetes Forum Bengaluru 2020: Auditing in Kubernetes 101 ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Auditing in Kubernetes 101 In this talk, Nikhita Raghunath will first go over what audit logs are and how to leverage them to stay informed with what goes on in your cluster. Keeping both performance impact and accountability in mind, she will then walk through examples of policy configurations to enforce best security practices, detect misuse and make your cluster more compliant. Nikhita will also do a demo of setting up auditing on a cluster and inspecting the logs. Finally, we will see what future improvements are planned for this feature and how you can provide feedback and get involved. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Kubernetes Forum Bengaluru: Get Startet as Contributor - **URL:** https://www.kubermatic.com/resources/kubernetes-forum-bengaluru-2020-keynote-getting-started-as-an-open-source-contributor-nikhita-raghunath-ihor-dvoretskyi/ - **Date:** 2022-12-01 - **Description:** Get insights on becoming a contributor and an active community member in the world of Kubernetes and open source. # Kubernetes Forum Bengaluru 2020: Getting Started as an Open Source Contributor ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Keynote: Getting Started as an Open Source Contributor Nikhita Raghunath, a Steering Committee member and a core contributor to Kubernetes; and Ihor Dvoretskyi, a long-term Kubernetes contributor, now a Developer Advocate at the Cloud Native Foundation, the largest open source foundation in the world, will share their insights on becoming a contributor and an active community member in the world of open source. Also, they will highlight the opportunities for those who are about to make their first steps in the open source contributions, including the programs as Google Summer of Code, Community Bridge by The Linux Foundation, Outreachy and others. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Kubernetes Forum Delhi 2020: Life of a Container - **URL:** https://www.kubermatic.com/resources/kubernetes-forum-delhi-2020-talk-indradhanush-gupta-life-of-a-container/ - **Date:** 2022-12-01 - **Description:** Why containers are nothing but a nicer UX for Linux namespaces and cgroups. # Kubernetes Forum Delhi 2020: Life of a Container ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Life of a Container What if I told you that there is no such thing as a container? Surprised? The first time I heard this I was taken aback as well. And when I started digging into the internals I found out that containers are nothing but a nicer UX for Linux namespaces and cgroups. If I wanted to run three instances of a web server serving traffic on port 80, do I need three separate machines? If you’re thinking yes, as no two processes can listen on the same port simultaneously, then the correct answer is no. Network namespaces make it possible to run them all under the same machine. And each of them can listen on the machine’s public network interface. In this talk you will find out what constitutes a container. The system calls invoked when a container is started, the resources used and their relation to the host OS and finally the teardown process when a container is deleted. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## KubeCon 2019: Implementing Major Prow features - **URL:** https://www.kubermatic.com/resources/kubecon-cloudnativecon-2019-implementing-major-prow-features/ - **Date:** 2026-03-17 - **Description:** Learn how and why we implemented Prow and what challenges we faced. # KubeCon + CloudNativeCon 2019: Implementing major Prow features ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## The how and why we implemented major Prow features In this session, Steve Kuznetsov from Red Hat and Alvaro Aleman from Kubermatic dive into some of the major features they added to Prow, including how they are implemented, and the challenges they faced. Examples include the new Prow monitoring stack, hooking up prow to other bug tracking systems than GitHub, and refactoring prow to support in-repo config to enable better self-service. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## KubeCon 2019: Becoming a Kubernetes Contributor - **URL:** https://www.kubermatic.com/resources/kubecon-cloudnativecon-2019-becoming-a-kubernetes-contributor/ - **Date:** 2022-12-01 - **Description:** KubeCon + CloudNativeCon 2019 # KubeCon + CloudNativeCon 2019: Becoming a Kubernetes Contributor ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## The journey from Kubernetes user, to member and beyond While the reasons for contributing to Kubernetes are diverse, we all share a passion for the community. This panel discussion covers the participants journey in becoming a member of Kubernetes, and share anecdotes on how to start contributing to Kubernetes, eventually obtain membership, and beyond. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## What Does the Kubelet Say? - **URL:** https://www.kubermatic.com/resources/what-does-the-kubelet-say/ - **Date:** 2022-12-01 - **Description:** Get a high level introduction before deep diving in the belly of the beast and its interfacing with CNI, container runtime and the Linux kernel. # What Does the Kubelet Say? ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## A Look at One of the Central Components in the Kubernetes Cluster Kubelet is one of the central components in the Kubernetes cluster. Most people are taking it for granted that it would just work and start containers. CNI handles the networking part, kube-proxy the service part, but kubelet does more than just starting containers. In this talk, Neven Miculinic will cover kubelet on a high level before deep diving in the belly of the beast and its interfacing with CNI, container runtime and ultimately the Linux kernel. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## KubeCon 2019: A Complete Look at the Kubernetes Dashboard - **URL:** https://www.kubermatic.com/resources/kubecon-cloudnativecon-2019-take-a-complete-look-at-the-kubernetes-dashboard/ - **Date:** 2022-12-01 - **Description:** Dive into the front-end and back-end development of the Kubernetes Dashboard # KubeCon + CloudNativeCon 2019: Take a Complete Look at the Kubernetes Dashboard ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Kubernetes (UI) SIG: Front-end and back-end development with the Kubernetes Dashboard Beast with many moving parts. With a front-end written in Angular, and a back-end written in go, the project has a complex set of needs to support development. The Kubernetes Dashboard is the primary way non-cloud-hosted Kubernetes clusters are managed and is a great introductory tool in a new cluster-admin’s belt. The Dashboard, much like Kubernetes itself, is a complex In this session, Jeffrey Sica from the University of Michigan and Sebastian Florek from Kubermatic will dive into both the front-end and back-end development with the Dashboard as well as outline progress with the 2019 SIG-UI Roadmap. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## KubeCon 2019: Get Started in the Kubernetes Community - **URL:** https://www.kubermatic.com/resources/kubecon-cloudnativecon-2019-get-started-in-the-kubernetes-community/ - **Date:** 2022-12-01 - **Description:** Kubernetes is its community. The foundation of this community lies on the Kubernetes Community Values. Learn what they are and why they are so important. # KubeCon + CloudNativeCon 2019: Get Started in the Kubernetes Community ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## What are the community values, why are they so important and how do they influence the ecosystem? Kubernetes is its community. The foundation of this thriving community lies on the Kubernetes Community Values. In this KubeCon 2019 keynote, Lucas Käldström, CNCF Ambassador, and Nikhita Raghunath from Kubermatic will take a look at what they are, why they are so important, and how they shaped the growing ecosystem. By first focusing on the core values, they will give you an idea of what it means to be involved and why you should contribute. After that, they will talk about how you can get started with contributing, move up the contributor ladder and become a regular contributor who serves the project. Lastly, they will look at some stories about how the existing contributors got started with their journey. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## KubeCon 2019: Fixing Kubernetes Clusters at Scale - **URL:** https://www.kubermatic.com/resources/kubecon-cloudnativecon-2019-fixing-kubernetes-clusters-at-scale/ - **Date:** 2022-12-01 - **Description:** How to secure Kubernetes clusters and to force upgrades to all of them in a scalable way # KubeCon + CloudNativeCon 2019: Fixing Kubernetes Clusters at Scale ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Securely operate and upgrade your clusters at scale As a hosting provider, SysEleven has the challenge to run and manage multiple Kubernetes clusters for various customers on their infrastructure in a secure way. The majority of these clusters are fully managed by them. Customers want to build and run containers, not maintain and upgrade them. In this talk, Simon Pearce from SysEleven and Sebastian Scheele from Kubermatic will give you a breakdown of how customers can secure their clusters and how to force Kubernetes upgrades to all of them in a scalable way. As an example the Kubernetes API bug occurred in December 2018 is used to show how to fix all clusters in a very short time frame. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## The Kubernetes Business Case: Better, Faster, Cheaper - **URL:** https://www.kubermatic.com/resources/better-faster-cheaper-the-business-case-for-kubernetes/ - **Date:** 2022-12-01 - **Description:** Learn about the business benefits of going cloud native and embarking your Kubernetes journey. # The Kubernetes Business Case: Better, Faster, Cheaper ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## The what, why, and business benefits of being cloud native For developers, the benefits of a cloud native approach are quickly clear. However, these advantages are not as readily apparent to people who don’t code – yet those same people usually hold decision making and budgetary power. In this talk, Bill Mulligan, Kubernetes Advocate at Kubermatic, explains the what, why, and business benefits of being cloud native without diving into code. Audience members will learn how to explain cloud native technologies to non-coders and give the business case for a cloud native approach at the organizational level. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Meet KubeOne: Our HA Kubernetes Cluster Management Tool - **URL:** https://www.kubermatic.com/resources/meet-kubeone-install-configure-upgrade-and-maintain-ha-kubernetes-clusters-anywhere/ - **Date:** 2024-03-22 - **Description:** Learn how to install, configure, upgrade and maintain HA Kubernetes clusters on any infrastructure # Meet KubeOne: Install, Configure, Upgrade and Maintain HA Kubernetes Clusters Anywhere ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Kubermatic's sponsored OS cluster lifecycle management tool for any infrastructure In search for a feature-complete solution that supports HA clusters, follows Kubernetes best-practices, and comes with a simple and declarative API based on the Kubernetes Cluster API, the Kubermatic dev team could not find a single one that fulfilled their needs. That’s why they decided to build KubeOne. KubeOne takes care of installing, configuring, upgrading and maintaining Highly-Available Kubernetes clusters. It works out-of-the-box on any cloud provider, as well as on-prem and in bare-metal environments. In this webinar, the two core contributors Marko Mudrinic and Artiom Diomin from Kubermatic will introduce KubeOne and show you how to get started. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## KubeCon 2019: A Smooth Kubernetes Contributor Experience - **URL:** https://www.kubermatic.com/resources/kubecon-cloudnative-con-2019-creating-a-smooth-kubernetes-contributor-experience/ - **Date:** 2022-12-01 - **Description:** KubeCon + CloudNative Con 2019 # KubeCon + CloudNative Con 2019: Creating a Smooth Kubernetes Contributor Experience ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Contributor Experience SIG: The automation and contributor flow roadmap In this 30 minute session, Nikhita Raghunath from Kubermatic and Christoph Blecker from Red Hat, speak about the SIG’s automation and contributor flow roadmap and highlight ways for you to get involved with creating a smooth experience for contributors of all levels. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## KubeCon 2019: A Global Cloud Native 5G Network - **URL:** https://www.kubermatic.com/resources/kubecon-cloudnativecon-2019-building-connecting-and-managing-a-global-cloud-native-5g-network/ - **Date:** 2022-12-01 - **Description:** Learn how cloud native technologies help enable the next generation of telco services. # KubeCon + CloudNativeCon 2019: Building, Connecting and Managing a Global Cloud Native 5G Network ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## Enabling the next generation of telco use cases with cloud native technologies 5G is forcing telecommunication companies to reconsider how to effectively and efficiently deliver their services. Many are looking towards cloud native architectures first pioneered in enterprise and data center use cases. The resilient, flexible, scalable, and automated paradigms that define cloud native are the perfect enablers for the next generation of telecommunication use cases. To demonstrate that building an end-to-end cloud native 5G network was not only possible but also has many advantages, LF Networking (LFN), which represents over 70% of the world’s mobile subscribers, lead a collaborative cutting-edge Proof-of-Concept with over 100 contributors. The participants wanted to illustrate how to build, connect, and manage a global 5G network – including on-prem, cloud, and edge operations – on open architecture running network services using Kubernetes. This cloud native 5G network was keynoted at KubeCon + CloudNativeCon North America. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Managing and Securing Enterprise Kubernetes - **URL:** https://www.kubermatic.com/resources/managing-and-securing-enterprise-multi-cluster-multi-cloud-kubernetes/ - **Date:** 2024-03-22 - **Description:** Learn how to centrally manage security policies across multi-cluster, multi-cloud deployments # Managing and Securing Enterprise Multi-Cluster, Multi-Cloud Kubernetes ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Webinar ## Centrally managing security policies across multi-cluster, multi-cloud deployments Failure to properly manage multiple Kubernetes clusters can lead to security holes, unauthorized deployments, and under-utilized resources. In this webinar, Tobias Hintze from Kubermatic and Dieter Reuter from NeuVector will team to offer best practices for multi-cluster management for Kubernetes. They will also show how tools from Kubermatic and NeuVector can simplify the deployment and management of new clusters, workloads, and security policies across the enterprise. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Kubernetes Operators: Next Level of Automation - **URL:** https://www.kubermatic.com/blog/why-kubernetes-operators-will-bring-you-to-the-next-level-of-automation/ - **Date:** 2026-05-07 - **Description:** Learn how Kubernetes Operators help you automate the operational burden of state-of-the-art cloud native applications and multi-cloud infrastructure. - **Categories:** Community - **Tags:** Open Source Projects - **Authors:** Kristin Wittig *Kubernetes has emerged as the world’s most powerful container orchestration platform, but its true power is hidden behind an extensible API and automation framework that will redefine how future platforms are built and operated.* Kelsey Hightower, Technologist, Google One of Kubernetes greatest – and most difficult to keep – promises is the ability to **automate the operational burden of state-of-the-art cloud native applications** and multi-cloud infrastructure. Kubernetes Operators deliver on this promise and even extend this operational automation to legacy software, allowing you to manage your applications just like a managed cloud service. However, before we dive into how Operators help businesses automate away time and nerve-intense operational toil, let’s take a step back and look at what a Kubernetes Operator actually is and does. Simply put: An Operator is a piece of software that understands how to run and facilitates operating another piece of software. More technically, as CoreOS, who introduced the first Kubernetes Operator in 2016, notes: An Operator is a **method of packaging, deploying and managing a Kubernetes application**. A Kubernetes application is an application that is both deployed on Kubernetes and managed using the Kubernetes APIs and kubectl tooling. An Operator has its custom controller watching the custom resources specifically defined for the applications. This allows developers to **codify life cycle management knowledge for applications** that need to maintain state and thereby automates much of the ongoing management including deployments, backups, upgrades, logging, and alerting by simply watching events and leveraging the reconciliation loops built into Kubernetes. For example, if Kubernetes detects the loss of a node in the cluster, an Operator can automatically create another node and join it to the cluster to bring the cluster back to the desired number of nodes. This simple example highlights the power of this paradigm. **Kubernetes Operators enable a whole new IT operational model** **that allows companies to scale through software rather than people.** This unlocks many benefits including: * Operators extend the power and automation of Kubernetes to a wide range of applications, particularly complex stateful apps * Operators take the error-prone human factor out of an application’s lifecycle management thereby improving resilience and facilitating large-scale deployments * Operators can be used like templates to automate application management, drastically improving scalability and repeatability * Operators facilitate multi and hybrid cloud management by eliminating the need for domain expertise Kubernetes Operators have continuously been growing in both quantity and popularity ever since they've been introduced. [Enterprise cloud native adoption](/blog/why-you-should-go-cloud-native-in-2020/) will reach the majority by 2023 and we are sure that Kubernetes Operators and their automation of application life cycle management will play a crucial role in that development. If you want to become a leader in the future of cloud native, there will be no way around Kubernetes Operators and automated application life cycle management. **To accelerate their growth and adoption, we are launching [OperatorCon](https://www.operatorcon.io/) as a Day Zero Conference at KubeCon Europe 2020 in Amsterdam**. If you want to learn from and exchange with the leading Operator experts, we look forward to seeing you there. #### Learn more: [O’Reilly: Kubernetes Operators: Automating the Container Orchestration Platform](https://www.oreilly.com/library/view/kubernetes-operators/9781492048039/) --- ## Why You Should Go Cloud Native in 2020 - **URL:** https://www.kubermatic.com/blog/why-you-should-go-cloud-native-in-2020/ - **Date:** 2026-05-07 - **Description:** Learn where enterprise cloud native adoption will be by 2023 and why it is high time to define your cloud strategy today. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Sebastian Scheele To kick off the decade, we make a prediction of where cloud native adoption will be by January 2023. We will also define where cloud native is currently on the adoption curve within large enterprises across all industries. We consider cloud native adoption to mean an enterprise running multiple clusters and where the majority of their enterprise applications are running as cloud native applications. **WE ARE HERE and We will BE THERE BY 2023** ![Enterprise cloud native adoption 2023 prediction](/static/Diffusion-of-Innovation.png) **How do we make this prediction?** In the [Enterprise Cloud Native Summit](https://www.ecn-summit.com), an exclusive gathering of European business and technology leaders driving digital transformation within their organizations, we asked attendees to rate their implementation of cloud native and Kubernetes on a scale from 0% (not yet started) to 100% (full implementation of Kubernetes clusters and cloud native applications) and mapped the results to the Diffusion of innovations theory from Everett Rogers. This data set also is consistent with what we are hearing from the hundreds of discussions and consultations we have with enterprises. **Why companies are going cloud native** In working with the most successful enterprises in the world, they tell us the four main challenges they face are: * Poor developer efficiency * Slow release cycles * Unstable products * Retaining and recruiting talent to build cloud native applications These IT leaders know that faster release cycles and automation in the deployment and management of applications greatly improves stability, innovation rate, and costs. They wisely recognize that going cloud native is the path to achieving their digital transformation goals. Implementing cloud native practices allows them to gain organization capacity to quickly innovate, use A-B feature testing, and reverting with ease as needed. One consistent theme is that they all have ambitious cloud native goals but most are stuck in the proof of concept stage or have only implemented a handful of applications. **Ambitious goals, but enterprises often stuck in POC or struggling to manage multiple clusters** When stuck, these enterprises have not yet crossed the chasm of cloud native adoption. Companies get stuck at the chasm for one or more of the following reasons: 1. Underestimating the complexity of cloud native technology 2. Not adopting the new business processes required of a cloud native IT organization 3. Failing to invest in winning the hearts and minds of the existing team to retool their skill set around cloud native We help companies cross this chasm, with Kubermatic Kubernetes Platform, our enterprise Kubernetes management platform and with customer consulting and training packages to accelerate companies on their cloud native journey. With our effort and that of our partners in the Cloud Native Computing Foundation ecosystem, we predict that the chasm will be crossed and that in the next three years, enterprises across every major vertical industry will cross into early majority. By January 2023, cloud native adoption will be at the peak of the diffusion curve, right in the middle of the graph. **Crossing the chasm in your organization** Kubermatic is known for Kubermatic Kubernetes Platform. By demand from our enterprise clients, we also created training and consulting to support enterprises’ cloud native journey. We help companies cross the chasm of cloud native adoption in the three critical areas of: * Designing a cloud native strategy and architecture * Mastering cloud native tooling, including Kubernetes and other tools * Upleveling the team cultures to thinking and operating cloud native To accelerate the cloud native journey, we offer consulting accelerator and training accelerator packages. These engagements last from 2 to 11.5 days and our enterprise customers have shared it has shaved off on average 4-6 months of the learning curve. An example of Kubermatic’s accelerator packages are: * [Cloud Native Accelerator for Developer](/consulting/cloud-native-for-developers/) * [Kubernetes Accelerator for Operator](/consulting/kubernetes-for-operators/) * [Application Migration Accelerator](/consulting/application-migration/) * [Kubernetes Operator Engineering Accelerator](/consulting/kubernetes-operator-engineering/) When tapping Kubermatic in their cloud native journey, enterprises are working with one of the top Kubernetes employers in Europe and the lead contributor to the Kubernetes Dashboard project in the Cloud Native Computing Foundation. Moreover, we were recently highlighted for [Kubermatic Kubernetes Platform’s](/products/kubermatic-kubernetes-platform/) role in delivering multi-cloud capability in the [KubeCon North America Keynote](https://www.lfnetworking.org/resources/2019/11/22/kubecon-keynote-e2e-5g-cloud-native-network/) on End-to-End 5G Cloud Native Network. At the start of this new decade, now is the time to reflect on your digital transformation goals and where your IT organization is on the cloud native journey. Here are a few questions to help you: * Do you have a cloud native strategy, road map and architecture in place? * Have you won the hearts and minds of your IT organization to transform their skills, mindsets, and processes? * Does your team have the technical skills for Kubernetes and other cloud native tools? If you surface any challenges in your plans contact us and we will help you resolve these challenges and greatly accelerate your journey to cloud native. **Learn more about our Kubermatic Kubernetes Platform Enterprise Software Solution, and [request a Demo](/demo/) to learn more** Kubermatic Kubernetes Platform is an enterprise software platform company that enables enterprises and service providers to deliver automated multi-cloud operations. Kubermatic Kubernetes Platform automates thousands of Kubernetes clusters across any infrastructure on multi-cloud, on-prem and edge with unparalleled density and resilience. With Kubermatic Kubernetes Platform, developers work with the cloud native stack they prefer and have freedom of choice and a consistent experience across all environments. By automating operations, teams focus on writing the next generation of ground-breaking applications, not operations. --- ## Death by a Thousand Scripts - **URL:** https://www.kubermatic.com/blog/death-by-a-thousand-scripts/ - **Date:** 2026-05-07 - **Description:** There is a trend of relying on scripts to fill the gaps left by the software system. This does not come without pitfalls. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Haresh Kheskani In my last five years of exposure to OpenSource Software, starting with OpenStack, I have noticed an increasing trend of relying on scripts to fill the gaps left by the software system. The gaps can be varied in their scope and size, such as * Installation * LifeCycle Management - Upgrades, Downgrades etc * Supporting different environments * Troubleshooting * Feature extensions While this approach may help with the initial PoC steps to get things off the ground, it can cause a lot of problems later on during the productization cycle. Ultimately, this leads to a software system that is heavily propped up by a multitude of scripts. Once the system goes into production, there are many scenarios where the scripts make the situation more challenging. For example, * In case of a failure, you are forced to debug your scripts before reporting the problem to the OpenSource community * In case of supporting a new environment, you have to rewrite all the scripts or create another set of scripts for the new environment * In case of feature extensions, all the scripts have to be updated for every OpenSource release * In case of troubleshooting hooks, all the scripts have to be updated for every OpenSource release * During the upgrade cycle of the OpenSource code base, the LifeCycle Management scripts are likely to require an upgrade * It is hard to build an end-to-end test system to validate your scripts * As time progresses, the code base of the scripts gets more and more complicated and hard to maintain Above all, this approach leaves you entangled in a web of customized scripts that results in a "snowflake" software system. As a result, you are largely left to solve your own problems without much support from the community or the relevant vendors. However, this unmaintainable pile of scripts does not have to be the inevitable status quo. By carefully choosing projects (open source) or products (proprietary) it is possible to reduce the number of scripts to a manageable amount or eliminate them completely. Based on my experience, they should be able to meet the following requirements: * Easy to install * Support Life Cycle Management * Support a variety of environments, as well as addition of new ones * Easy to troubleshoot * Support feature extensions/additions * Production Ready which includes quality, scalability, etc In the case of an OpenSource project, the architecture should be flexible and modular enough so that you can fill the gaps by contributing to the project. While in the case of a proprietary product, the architecture should allow the vendor to be able to fill the gaps in short order. At Kubermatic, we develop both open source and proprietary products that address this issue and help businesses avoid creating snowflake systems: * **KubeOne**, our lifecycle management tool for single HA Kubernetes clusters on any cloud provider, is a great example. KubeOne makes it easy to deploy and manage best-in-class Kubernetes clusters on any environment and comes with native support for major providers including AWS, Azure, DigitalOcean, GCP, OpenStack and VMware vSphere. At the same time, it gives you room to support any other new environment by contributing to the open source project. For more info:[ /blog/kubeone-simplified-lifecycle-management-for-ha-kubernetes-clusters/](/blog/kubeone-simplified-lifecycle-management-for-ha-kubernetes-clusters/) * **Kubermatic Kubernetes Platform**, Kubermatic’s multi-cluster on multi-cloud Kubernetes platform is a great example of this. This product was developed after a lot of experimentation with scripts which were tailormade for specific environments which turned into a maintenance nightmare. With the new approach (sans scripts), it takes a few days to add support for a new cloud provider. Today,Kubermatic Kubernetes Platformstands out for its reliability, flexibility and general applicability as the Kubernetes platform of choice. For more info -</products/kubermatic-kubernetes-platform/> In general, scripts are meant for PoC and prototyping phase, not for productization. At the time of production, you should be able to raise both your arms up and say "Look Ma, no scripts". --- ## Time Is Running For Google Cloud - **URL:** https://www.kubermatic.com/blog/time-is-running-for-google-cloud/ - **Date:** 2026-05-07 - **Description:** Google has set 2023 as the deadline to beat Amazon and Microsoft in cloud. What if Google would end the life of your IT on GCP within three years from now? - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Sebastian Scheele I bet your Kubernetes and cloud strategy didn’t plan for GCP to go out of business? As co-founder of one of the leading Kubernetes Management product suites available today, I hear the transformative ideas enterprise IT leaders are driving through their organizations on a daily basis. And their concerns and challenges with today's enterprise and cloud software landscape. I listen to their need to support multiple cloud providers based on regional data or latency requirements. I hear about price competitiveness and the desire to avoid vendor lock-in from one of the three major cloud providers AWS, Azure, and GCP. But what I haven't heard is: "Google could end of life of my IT on their GCP by within 3 years." And yet, based on this <a href="https://www.theinformation.com/articles/google-brass-set-2023-as-deadline-to-beat-amazon-microsoft-in-cloud?utm_source=hackernews&utm_medium=unlock"> latest revelation </a>, I am already getting phone calls about this topic. Fortunately for Kubermatic customers, Kubermatic Kubernetes Platform is designed from day one to move workloads across clouds with a click of a button. In addition, we support VMware, Openstack, Bare-Metal and many more. With Thomas Kurian leading GCP, Google has wisely recognized that the issue is not so much in their technology, but in their go-to-market strategy. Kurian is placing large bets and executing efficiently to build out Google sales, sales engineering, and field facing engineering teams to support enterprise use cases. However, with over 44 product EOL'ed in the last 3 years (<a href="https://gcemetery.co/google-product-lifespan/">https://gcemetery.co/google-product-lifespan/</a>), all enterprise cloud customers should be prepared for large changes as public cloud market evolves – and changes not just from Google Cloud. As one of the top Kubernetes employers, we take the insights and concerns from our customers to deliver open source core based solutions that allow you to focus on application development and deployment while our enterprise software takes care of your day 2 operations and the constantly evolving vendor and technology landscape. If you don’t want to worry about vendor lock-in or today’s top of mind question, “is time running out on your cloud provider,” let me show you how Kubermatic Kubernetes Platform can help you achieve your cloud native transformation goals. <img src="/static/Kubermatic-Kubernetes-Platform.png" alt="Kubermatic Kubernetes Platform chart" /> #### Learn more <ul> <li> <a href="/products/kubermatic-kubernetes-platform/"> Learn more about Kubermatic Kubernetes Platform </a> </li> <li> <a href="https://www.theinformation.com/articles/google-brass-set-2023-as-deadline-to-beat-amazon-microsoft-in-cloud?utm_source=hackernews&utm_medium=unlock"> Article: Google Brass Set 2023 Deadline to Beat Amazon, Microsoft in Cloud </a> </li> <li> <a href="https://www.cnbc.com/2019/07/25/google-cloud-at-8-billion-in-sales-a-year-and-is-tripling-sales-force.html"> Article: Google Cloud in generating $8 billion in revenue a year </a> </li> </ul> --- ## KubeCon San Diego Recap: A great, but hell of a busy week - **URL:** https://www.kubermatic.com/blog/kubecon-san-diego-recap/ - **Date:** 2026-05-07 - **Description:** Once again a KubeCon did not disappoint. With over 12.000 attendees, San Diego was another record breaking conference filled with Kubernetes excitement. - **Categories:** Community - **Tags:** Kubernetes, Open Source Projects - **Authors:** Paul Müller Once again a KubeCon did not disappoint. With over 12.000 attendees and almost 250 exhibitors, San Diego was another record breaking conference filled with Kubernetes excitement. But, let’s start from the beginning. We kicked off the week with our SIG-Bike tour through the city and the nearby hills. The jetlag didn’t help but we managed. Coming from rainy Northern Germany the San Diego autumn seems like paradise. ![KubeCon San Diego Bike Tour](/static/kubecon-san-diego-2019_bike-tour.jpg) KubeCon itself was a lot of work but also a ton of fun. It was really exciting to see so many people stop by our booth to see our Kubermatic Kubernetes Platform demo and, of course, to get some german chocolate and a Loodsie sticker or two. ![KubeCon San Diego Exhibition Hall Team Loodse](/static/kubecon-san-diego-2019_exhibition-hall_team.jpg) We were really proud that two of our colleagues, Alvaro and Nikhita, got to share their Kubernetes expertise at the conference. Alvaro, together with Steve from Red Hat, did a Deep Dive into <a href="https://www.youtube.com/watch?v=_MQdTKn1nfI&list=PLytD1l2uNPnwRhKYZMBu2BsZ1BTEqeeCz&index=3&t=0s">Prow</a>. At Kubermatic, we are making extensive use of Prow, Kubernetes own CI/CD framework, for our public and private projects. So Alvaro and Steve shared some of the major features we added and the challenges we faced in doing that. <div style="padding:28%; position:relative; display:block;"> <iframe id="ViostreamIframe" width="100%" height="100%" src="https://www.youtube.com/embed/_MQdTKn1nfI" frameborder="0" allowfullscreen="" style="position:absolute; top:0; left: 0" > </iframe> </div> As Technical Lead for SIG Contributor Experience, Nikhita gave a Deep Dive into the <a href="https://www.youtube.com/watch?v=0d97Wna4qOs&list=PLytD1l2uNPnwRhKYZMBu2BsZ1BTEqeeCz&index=2&t=0s"> automation and contributor workflow </a> roadmap to smoothen the experience for contributors of all levels. As part of the Steering Committee she also took part in a panel discussion on the state of the <a href="https://www.youtube.com/watch?v=0Su1kKlr9q0&list=PLytD1l2uNPnwRhKYZMBu2BsZ1BTEqeeCz&index=4&t=998s"> Kubernetes Union </a>. Both are a must see if you are part of the Kubernetes project. You can find all recordings in the learn more section at the end of the post. <div style="padding:28%; position:relative; display:block;"> <iframe id="ViostreamIframe" width="100%" height="100%" src="https://www.youtube.com/embed/0d97Wna4qOs" frameborder="0" allowfullscreen="" style="position:absolute; top:0; left: 0" > </iframe> </div> But the definitiv highlight of the whole week was the KubeCon keynote address we are so excited to have been part of. Showcasing Kubermatic Kubernetes Platform running an end to end cloudnative 5G demo was amazing – although also a little bit nerve-racking. Check out our <a href="/blog/kubecon-the-first-cloud-native-5g-live-demo-ever/">recap of the session</a> or go straight to the source and <a href="https://www.youtube.com/watch?v=IL4nxbmUIX8">watch the recording.</a> To end a long and tiring few days, we went hiking on friday and enjoyed the fantastic scenery of the surrounding hillside. We for one can’t wait to see everyone again and are looking forward to KubeCon Amsterdam next year. #### Learn More <a href="https://www.youtube.com/playlist?list=PLytD1l2uNPnwRhKYZMBu2BsZ1BTEqeeCz">Watch all recordings here</a> --- ## KubeCon: The First Cloud Native 5G Live Demo Ever - **URL:** https://www.kubermatic.com/blog/kubecon-the-first-cloud-native-5g-live-demo-ever/ - **Date:** 2026-05-07 - **Description:** LF Networking lead a collaborative cutting-edge Proof-of-Concept to deliver a fully containerized 5G network live on stage in San Diego. - **Categories:** Community - **Tags:** KKP, Events, Open Source Projects - **Authors:** Bill Mulligan 5G networks are poised to deliver low-latency, high-bandwidth, scalable networks to consumers and businesses worldwide. This next generation of networks is desperately needed to deliver the required high-speed connectivity to support new services and use cases like autonomous vehicles, smart cities, specialized applications, IoT, and AR/VR. While 5G networks supply unparalleled performance, capabilities, and automation for operators, they also place high demands upon them. Conventional communications and connectivity hardware is not capable of sustaining these challenging requirements. 5G is forcing telecommunication companies to reconsider how to effectively and efficiently deliver their services. Many are looking towards cloud native architectures first pioneered in enterprise and data center use cases. The resilient, flexible, scalable, and automated paradigms that define cloud native are the perfect enablers for the next generation of telecommunication use cases. To demonstrate that building an end-to-end cloud native 5G network was not only possible but also has many advantages, LF Networking (LFN), which represents over 70% of the world’s mobile subscribers, lead a collaborative cutting-edge Proof-of-Concept with over 100 contributors. The participants wanted to illustrate how to build, connect, and manage a global 5G network – including on-prem, cloud, and edge operations – on open architecture running network services using Kubernetes. This cloud native 5G network was keynoted at KubeCon + CloudNativeCon North America. The demo showed a live prototype running in labs around the world using Kubernetes and other open source technologies to deliver a fully containerized 5G network on stage in San Diego and carry out a phone call with a person in France. ![LF Networking Keynote at KubeCon 2019 San Diego](/images/blog/2019-12-04/2019-12-04_00-20-00.jpg) As a part of the demo, we were extremely excited and proud to provide the Kubermatic Kubernetes Platform for Kubernetes cluster orchestration. Kubermatic Kubernetes Platform simplified the life cycle management of the many clusters running across multiple providers needed in this demonstration. “5G opens many exciting new business opportunities and Kubernetes is poised to be the unified base upon which 5G is delivered. With the cloud native 5g demo, Kubermatic is excited to showcase how the Kubermatic Kubernetes Platform can deliver a consistent Kubernetes experience from cloud to core to edge,” said Sebastian Scheele, CEO, Kubermatic. ![LF Networking Keynote KubeCon 2019: 5G RAN & Edge compute](/images/blog/2019-12-04/Blog_VCO%20Setup.png) The keynote showed the world that cloud native 5G is not only possible but here today. The learnings from the PoC will be contributed and integrated into standards and verification bodies, like CNTT, to help inform the best practices for the next generation of networks. With over 100 individuals from 14 companies working on the demo, it truly represents the power of open source: diverse groups coming together to solve common challenges. Bringing cloud native approaches to telco to run demanding 5G networks is just the latest. We would love to thank all of the other organizations that participated in this effort: [A10 Networks](https://www.a10networks.com/), [A10 Networks](https://www.a10networks.com/), [Alibaba](https://www.alibaba.com/), [Altran](https://www.altran.com/us/en/), [China Mobile](https://www.chinamobileltd.com/en/global/home.php), [Commscope](https://www.commscope.com/), [Eurecom](http://www.eurecom.fr/en), [Intel](https://www.intel.com/), [Kaloom](https://www.kaloom.com/), [Lenovo](https://www.lenovo.com/us/en/), [NetScout](https://www.netscout.com/), [OpenAirInterface](https://www.openairinterface.org/), [Red Hat](https://www.redhat.com/en/solutions?sc_cid=701f2000001D7iwAAC&gclid=EAIaIQobChMIq-WR8ZvR5QIVcRh9Ch3SNQUUEAAYASAAEgKQ8_D_BwE&gclsrc=aw.ds), and [Turnium](https://turnium.com/). ### Where to learn more and get involved: See the keynote yourself [here](https://www.youtube.com/watch?v=IL4nxbmUIX8). More information is accessible via the [POC archive here](https://wiki.opnfv.org/display/OSDD/OPNFV+VCO+Demo+Discussion+Home) where demo materials will be made available, as well as through the Virtual Central Office (VCO) mailing list: <https://lists.opnfv.org/g/opnfv-vco>. Find out about [CNTT here](https://wiki.lfnetworking.org/display/LN/Common+NFVI+Telco+Task+Force+-+CNTT). A CNTT Face to Face meeting will take place in Prague as part of the [LFN Developer & Testing Forum](https://events19.linuxfoundation.org/events/lf-networking-ddf-plugfest-2020/), January 2020. The Virtual Network Functions (VNF) testing hacking track team are open to CNF/PNF participants as well. Please contact [ovp-support@lfnetworking.org](mailto:ovp-support@lfnetworking.org). --- ## More Freedom of Choice With Native Support of KubeVirt - **URL:** https://www.kubermatic.com/blog/introducing-kubermatic-kubernetes-platform-2-12/ - **Date:** 2026-05-07 - **Description:** The latest Kubermatic Kubernetes Platform 2.12 release comes with native KubeVirt support, enhanced security features and improved user management. - **Categories:** Products - **Tags:** KKP - **Authors:** Kristin Wittig The world doesn’t stand still and neither do we. We are constantly working on improving and optimizing Kubermatic Kubernetes Platform, our enterprise-grade Kubernetes Management Platform for any infrastructure. Today, we are proud to announce the release of Kubermatic Kubernetes Platform 2.12. Here is an overview of the most important changes. #### More Freedom of Choice With Native Support of KubeVirt Kubermatic Kubernetes Platform 2.12 comes with native support for [KubeVirt](https://github.com/kubevirt), the Kubernetes Virtualization API and runtime to define and manage virtual machines. This enables DevOps teams to use existing cloud native technologies with their physical hardware and use it to provision Kubernetes. #### Security and Auditability From Day #1 Kubermatic Kubernetes Platform provides enterprise-grade security and compliance. With the latest release, we introduce the ability to enable Pod Security Policies as well as Audit Logs for the user clusters from the UI. Everything that happens inside Kubermatic Kubernetes Platform-managed clusters is constrained and logged according to your specific needs. #### Improved User Management Kubermatic Kubernetes Platform 2.12 comes with enhanced features for user management, including the possibility to manage access to data centers and to configure cloud credentials as presets. With its user management features, Kubermatic Kubernetes Platform provides IT operators with a self-service platform to enhance the DevOps experience while also living up to enterprise standards and keeping control. #### Run Kubernetes And OpenShift As You Like Kubermatic Kubernetes Platform now supports Kubernetes 1.16 and OpenShift 4.1. To meet the highest security and reliability standards, we always run Kubermatic Kubernetes Platform master components with the Kubernetes version that addresses recently discovered vulnerabilities. To receive our Kubernetes Security Updates, sign up here: [/newsletter/](/company/newsletter/). <br> For more information, see the entire Kubermatic Kubernetes Platform 2.12 changelog here: <br> https://docs.kubermatic.io/changelog/2.12/ --- ## Cloud Native Best Practices #5: Observability & Monitoring - **URL:** https://www.kubermatic.com/blog/cloud-native-best-business-practices-5-observability-monitoring/ - **Date:** 2026-05-07 - **Description:** Cloud native observability and monitoring are essential to provide a better level of customer service through faster discovery of problems. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Bill Mulligan To [quote Michael Dell](https://www.forbes.com/sites/richkarlgaard/2017/08/08/how-michael-dell-reinvented-his-company/?linkId=40742788#208a6a9548a7), “the cloud isn’t a place, it’s a way of doing IT.“ As IT becomes more and more central to what every company does, understanding cloud native best practices is key not only for the IT department – but for every part of a business. This post is the fifth of a seven-part series examining how cloud native can help businesses deliver on their promise of better, faster, and cheaper. This part shows how observability and monitoring are key to providing a **better level of service** to customers through the **faster discovery of problems** all while **identifying areas to reduce costs.** #### Cloud Native Best Business Practices: Observability and Monitoring To keep up with the quickening pace of business, companies are increasingly turning towards cloud native technologies with [70% of enterprises](https://www.oreilly.com/pub/pr/3278) reporting that they are beginning to adopt or have already adopted them. A cornerstone of the [cloud native technology definition](https://github.com/cncf/toc/blob/master/DEFINITION.md) is observability because it helps companies monitor the health of and optimize the resource consumption of their applications and infrastructure. The importance of observability is also seen in project adoption with Prometheus, the open source monitoring system, becoming the second project, behind Kubernetes, [to graduate](https://www.cncf.io/announcement/2018/08/09/prometheus-graduates/) from the Cloud Native Computing Foundation. Many companies implement Prometheus with Grafana for an open source monitoring stack or turn towards one of the many vendors on the CNCF Landscape. The benefits of observability and monitoring extend far beyond a green status dashboard directly to the bottom line. As IT departments have grown from a few servers blinking in a backroom to sprawling landscapes of different deployments across multiple data centers and cloud providers, it has become increasingly difficult to even keep track of computing infrastructure, let alone optimizing operations. In an always-on world where consumers and customers expect constant uptime, any impact on application performance can almost immediately be felt by the end user with IT downtimes costing an average of $336,000 per hour. Clearly, being able to quickly – or even proactively – identify any IT problem not only saves companies money, but also provides a better service to their customers. Looking through the list of [Kubernetes Failure Stories](https://k8s.af/), almost every story begins with the operators noticing a degradation of performance in their monitoring system of choice. Monitoring dashboards come up the latest when the debugging begins. When a production outage started, [Grafana Labs](https://grafana.com/blog/2019/07/24/how-a-production-outage-was-caused-using-kubernetes-pod-priorities/) was able to identify and mitigate the problem in under 10 minutes because they had proper observability in place, including both monitoring and logging. Observability is key to not only finding, but also solving the problems. [Slamtec](https://www.cncf.io/case-study/slamtec/) reduced the time spent on debugging and troubleshooting by 50% when they implemented centralized monitoring with Prometheus and Fluentd. Implementing monitoring and observability gives companies the ability to quickly spot and service problems before they begin to have major impacts on customers and the bottom line. However, observability and monitoring are not only about watching for things to go wrong, they can also help optimize when things are going well. Cloud native technologies provide a powerful platform to dynamically create infrastructure. In many companies, this ability is spread across a multi-tenant (and sometimes multi-cloud) environment. This can create a tragedy of the commons problem where teams overprovision resources to ensure their applications run smoothly. Today, companies waste $14.1 Billion per year on idle and over-provisioned computing resources. By implementing monitoring to understand how effectively resources were being used, the team at [Kubecost](https://kubecost.com/) helped companies reduce their infrastructure spend by [30-70%](http://blog.kubecost.com/blog/cost-monitoring/) with one even realizing they were overspending by 500%! The inability to effectively track computing resources clearly impacts the bottom line in multiple ways. We built [Kubermatic Kubernetes Platform](https://kubermatic.io/) with an out-of-the-box integration of Prometheus and Grafana to give our customers the industry-standard open-source tools for observability and monitoring. This allows our customers to have better insight into and oversight of their infrastructure. Using these tools and our Kubermatic Kubernetes Platform operators, we help our customers gain awareness of both the health and cost of their infrastructure. You can read more about how we implemented it [here.](/blog/monitoring-prow-resources-with-prometheus-and-grafana/) This allows them to effectively monitor and fix problems before their customers notice and optimize infrastructure costs, including internal chargebacks. Observability and monitoring help cloud native companies create more reliable services with faster time to recovery while improving the bottom line through reduced outages and cost optimization. Check out part six: security and compliance to understand the impact of cloud native upon the biggest concern for every enterprise. --- ## Proud to have Nikhita elected to the K8s Steering Committee - **URL:** https://www.kubermatic.com/blog/proud-to-have-nikhita-elected-to-the-k8s-steering-committee/ - **Date:** 2026-05-07 - **Description:** Nikhita Raghunath is a core contributor to Kubernetes and the technical lead for SIG Contributor Experience. - **Categories:** Community - **Tags:** Kubernetes, Open Source Projects - **Authors:** Kristin Wittig We are very proud to have our software developer Nikhita Raghunath elected to the [Kubernetes Steering Committee.](https://github.com/kubernetes/steering) Nikhita is a core contributor to Kubernetes and the technical lead for [SIG Contributor Experience.](https://github.com/kubernetes/community/tree/master/sig-contributor-experience) She is also a CNCF Ambassador and runs the [GSoC](https://github.com/cncf/soc#organization-admins) and [Outreachy](https://www.outreachy.org/communities/cfp/kubernetes/) internship programs for CNCF/Kubernetes, as well as being a keynote speaker at KubeCon Barcelona in the past. She is very involved in growing the community, by improving contributor sustainability, encouraging people to get started with Kubernetes, and an advocate for diversity within it. We can’t think of anyone more fitting to be elected to the committee and think it’s well deserved. The 2019 Steering Committee Election is a landmark milestone for the Kubernetes project. The initial bootstrap committee is graduating and the committee has now shrunk to its final size of seven seats. All members are now fully elected by the Kubernetes Community. Moving forward, elections will elect either 3 or 4 people to the committee for two-year terms. #### Results Next to Nikhita, the following candidates secured two-year terms that start immediately: * Christoph Blecker , Red Hat * Derek Carr , Red Hat * Paris Pittman , Google They are joining Aaron Crickenberger, Google; Davanum Srinivas, VMware; and Timothy St. Clair, VMware. The seats held by Aaron, Davanum, and Timothy will be up for election around this time next year. #### Get Involved with the Steering Committee You can follow the Steering Committee backlog items and weigh in by filing an issue or creating a PR against their repo. They meet bi-weekly on Mondays at 6pm UTC and regularly attend Meet Our Contributors. They can also be contacted through their public mailing list [steering@kubernetes.io.](mailto:steering@kubernetes.io) #### Kubermatic Open Source Projects At Kubermatic, we believe that open source communities develop better software to the benefit of all. We stand behind what we believe by actively contributing to upstream Kubernetes, cloud native technologies, and other projects that facilitate the adoption of multicloud operations. Check out our own open source projects to learn more. Machine-controller: https://github.com/kubermatic/machine-controller <br> KubeOne: https://github.com/kubermatic/kubeone --- ## Monitoring Prow Resources with Prometheus and Grafana - **URL:** https://www.kubermatic.com/blog/monitoring-prow-resources-with-prometheus-and-grafana/ - **Date:** 2026-05-07 - **Description:** Learn the basics about Prow, how to set it up, integrate and monitor. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Christoph Mewes At Kubermatic we’re making extensive use of [Prow](https://github.com/kubernetes/test-infra/tree/master/prow), Kubernetes’ own <abbr title="Continuous Integration/Delivery">CI/CD</abbr> framework, for our public and private projects. Prow is responsible for managing source code builds which are usually triggered by creating Pull Requests (PRs) on our GitHub repositories or sometimes periodically for nightly cleanup jobs. Besides just running build jobs, it can also act as a fully-featured GitHub bot for performing manual tasks or merging PRs once a certain set of criteria is met. As with any Kubernetes cluster, monitoring is essential. If your developers are having an especially productive day, the workload on your cluster increases and jobs slow down. They now start to influence each other, compete for resources and once things get slower (god help you if your system would swap), you run into random timeouts, tests become flaky and developer happiness is reduced. Prow itself does offer a rudimentary, web-based UI to see the pending and running jobs and, most importantly, inspect a job’s logs in case of errors. This however is not really useful for monitoring your cluster over time (and it’s not meant to be a long-term statistic), so we recently spent some time on improving our setup and decided to share the results. #### The Basics Our Prow setup consists of two separate Kubernetes clusters: the control plane and the worker cluster. The control plane runs, as its name implies, the Prow control plane. These components have access to GitHub credentials and so we decided to separate it from the actual build workload, which runs on the “worker cluster”. Prow does offer some native metrics, but this article only covers data that we can scrape inside the worker cluster. For monitoring the control plane itself, there is already some [prior art](https://github.com/kubernetes/test-infra/tree/master/prow/cluster/monitoring) used by the Kubernetes project itself. But once again, this focuses on runtime metrics of the control plane and not really the resource usage of our workers. The monitoring setup is as simple as it gets: We’re using the [Prometheus Operator](https://github.com/coreos/prometheus-operator) to deploy the stack for us and then just inject a couple of custom Prometheus rules and Grafana dashboards. If you already have a monitoring stack running, you can skip the operator and just use the metrics from [kube-state-metrics.](https://github.com/kubernetes/kube-state-metrics) #### Setup Installing Prow is out of scope for this article, so please refer to the well written [installation instructions](https://github.com/kubernetes/test-infra/blob/master/prow/getting_started_deploy.md) for more information on that topic. For the rest of this article we’re assuming you have set up Prow and configured your KUBECONFIG variable to point to your cluster. The first step is to install [Helm’s](https://helm.sh/) Tiller (Helm is a Kubernetes package manager and we will use it to make installing additional software easier) into the cluster. To be a good cluster citizen we’re creating a dedicated service account for Tiller, even though we will give it cluster-admin permissions anyway: ```bash $ kubectl create serviceaccount -n kube-system tiller $ kubectl create clusterrolebinding tiller-cluster-role --clusterrole=cluster-admin --serviceaccount=kube-system:tiller $ helm --service-account tiller --tiller-namespace kube-system init ``` <br> Now that Tiller is hopefully running, we can install the vanilla [Prometheus Operator chart](https://github.com/helm/charts/tree/master/stable/prometheus-operator) (in the real world you would probably make a healthy amount of adjustments to the operator) into a new monitoring namespace: ```bash $ helm --tiller-namespace kube-system install --namespace monitoring --name prometheus-operator stable/prometheus-operator ``` <br> Give your cluster a bit of time and you should soon see a handful of pods running: ```bash $ kubectl -n monitoring get pods NAME READY STATUS RESTARTS AGE alertmanager-prometheus-operator-alertmanager-0 2/2 Running 0 3h15m prometheus-operator-grafana-779cbbd695-x87mm 2/2 Running 4 3h15m prometheus-operator-kube-state-metrics-6f7cdf99cd-bvxww 1/1 Running 0 3h15m prometheus-operator-operator-56fc8d5b58-rlsj7 1/1 Running 0 3h15m prometheus-operator-prometheus-node-exporter-4pzfs 1/1 Running 0 3h15m prometheus-operator-prometheus-node-exporter-5tt7g 1/1 Running 0 3h15m prometheus-operator-prometheus-node-exporter-6d6m6 1/1 Running 0 3h15m prometheus-operator-prometheus-node-exporter-6m2dr 1/1 Running 0 3h15m prometheus-operator-prometheus-node-exporter-7h8gl 1/1 Running 0 3h15m prometheus-operator-prometheus-node-exporter-9m99f 1/1 Running 0 3h15m prometheus-operator-prometheus-node-exporter-gcpwp 1/1 Running 0 3h15m prometheus-operator-prometheus-node-exporter-hhh95 1/1 Running 0 3h15m prometheus-operator-prometheus-node-exporter-j44kk 1/1 Running 0 3h15m prometheus-operator-prometheus-node-exporter-mf5np 1/1 Running 0 3h15m prometheus-operator-prometheus-node-exporter-rmfrs 1/1 Running 0 3h15m prometheus-operator-prometheus-node-exporter-smxbk 1/1 Running 0 3h15m prometheus-operator-prometheus-node-exporter-tql7j 1/1 Running 0 3h15m prometheus-prometheus-operator-prometheus-0 3/3 Running 1 3h4m ``` <br> Prow jobs run as regular Kubernetes pods in a namespace you choose when setting up Prow. In our setup, we’re using the default namespace. Kube-state-metrics will now already publish all the metrics we need for our dashboards: Prow puts a bunch of metadata into labels onto the pods, so for a basic monitoring setup it’s sufficient to rely on those metrics. More data is available inside the control plane cluster and you could also write a dedicated Prow Exporter, but for now the existing metrics are plenty. However, the plentiful metrics are hard to use and can lead to slow queries. We would have to merge pod labels, status, job labels and resource metrics on the fly. Not something we want on a dashboard that re-runs the same queries over and over again. Instead we’re going to define a set of recording rules for Prometheus to create neat, tidy metrics that can be easily visualized. When using the Prometheus Operator, new rules can be defined by creating a PrometheusRules resource containing the rules: ```yml apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: prow-rules namespace: monitoring labels: app: prometheus-operator release: prometheus-operator spec: groups: - name: prow rules: # These metrics are based on generic pods, not just Prow jobs. # group interesting information into a single metric # squash metrics from multiple kube-state-metrics pods # {namespace="...",pod="...",node="...",pod_ip="1.2.3.4",phase="..."} 1 - record: prow:pod expr: | max by (namespace, pod, node, pod_ip) (kube_pod_info) * on (namespace, pod) group_left (phase) (kube_pod_status_phase{namespace="default"} == 1) ``` (The full set of rules is available on [GitHub.](https://github.com/loodse/prow-dashboards)) Note that we filtered not only the pods by namespace, but also only took node named worker-... into account for calculating node resource usage. Depending on your setup, you might want to tweak the rules a bit. Afterwards, apply the new rules using kubectl ```bash $ kubectl -n monitoring apply -f prometheus-rules.yaml ``` and then port-forward into your Prometheus to make sure the rules have been loaded successfully (open [http://127.0.0.1:9090/rules](http://127.0.0.1:9090/rules) after running this command): ```bash $ kubectl -n monitoring port-forward prometheus-prometheus-operator-prometheus-0 9090 ``` <br> You should be able to see the new prow group and its rules: <img src="/images/blog/2019-09-10/image2.png" alt="prow" width="100%"/> <br> The final step is to create a set of handy dashboards to allow our developers a quick overview over the available and consumed resources. Adding custom dashboards is straightforward: Create a new ConfigMap, put each dashboard as a JSON file in it, label it with grafana_dashboard=1 and it will be picked up automatically. The GitHub repository linked above has a ready-made ConfigMap in it, so let’s apply it: ```bash $ kubectl -n monitoring apply -f dashboards-configmap.yaml ``` #### Profit! After all this you should be able to see four new dashboards labelled with “prow” in your Grafana. <br> <img src="/images/blog/2019-09-10/image3.png" alt="Grafana" width="100%"/> <br> You can reach Grafana just like Prometheus by doing a port-forwarding: ```bash $ kubectl -n monitoring port-forward service/prometheus-operator-grafana 3000 ``` <br> The dashboards are ordered hierarchically: You go from organisations to repositories to jobs and finally to individual builds. For a single company the Repositories dashboard is a good starting point: <img src="/images/blog/2019-09-10/image7.png" alt="Grafana" width="100%"/> <br> The top left has a list of repositories, which you can use to drill down further. The top has a table listing all jobs (of the chosen organisation) that are stuck in pending. In a perfect world, this table is always empty. Below are charts giving an overview over the running jobs and resource consumption. The gauges on the left contrast the requests to their actual usage. In this sense, the two gauges on the left can go above 100% (indicating that you request more resources than the cluster has available), whereas the two gauges on the right should never exceed 100%. Below that are rows for each repository where the resources are broken down individually, allowing you to easily judge the repository’s resource constraints. All configurations and dashboards are available on GitHub under the Apache License. #### Learnings There are a couple of things we’ve learned over time, most importantly that good resource **requests** are essential to prevent your cluster from overloading itself. This is of course true for any healthy Kubernetes cluster, but the spotty nature of CI workloads amplifies the importance of resource scheduling. Using the dashboards it’s easy to get a good feeling for how much resources a job usually takes and adjust the requests accordingly. The screenshot below shows what can happen if requests are set too high. If you plan for the worst case and set high requests, it’s very possible that you underuse your cluster and waste developer time because jobs are needlessly waiting their turn. If you see patterns like in the image on the left, consider reducing your resource requests. <br> <img src="/images/blog/2019-09-10/image1.png" alt="Memory" width="100%"/> <br> A common reason for running into this situation are jobs that are very spotty in the CPU usage, for example when running end-to-end tests against remote environments. In such tests most of the build time is spent just waiting for conditions to be met, but intermittently a lot of CPU is required for building binaries or Docker images before or after tests. The image below shows how the resource request is set to 0.5 CPU cores, but the container is allowed to spike and use up to 2 cores. <br> <img src="/images/blog/2019-09-10/image6.png" alt="CPU" width="100%"/> <br> The resource requests for builds should target the average resources needed, not the maximum, or else you will run into congestion issues. Assume that spotty jobs are not all requiring their resources at the same time. With resource **limits** the story is more complicated. Jobs should always have proper **memory** limits, just like with every other pod we ever deploy into any Kubernetes cluster. CPU limits are not so easy. While it’s tempting to also set limits according to the average usage, this will artificially slow down your jobs if the nodes would have capacity to spare. Not having a limit at all could let jobs interfere with cluster services like log shippers, the kubelet or others. For us it worked well to have limits close the node capacity (like 3.5Gi on a machine with 4GiB memory). If your jobs are not timing-sensitive (for example if you mainly compile artifacts or run only unit tests), it’s okay if multiple jobs run on the same node: the operating system will take care of scheduling between them and your build artifacts will take a bit longer to produce. If your jobs however depend on external services or you run end-to-end tests, having a process be slowed down can lead to timeouts and flaky tests. In this case we made sure to set high enough CPU requests to prevent multiple sensitive jobs from running on a single node. All in all the new dashboards gave us a much better feeling for the resources our build jobs actually consume. It made the data not just available to the cluster operators, but to all the teams actually using the cluster. #### On the Horizon Many of the lessons on what constitutes interesting metrics will make their way into Kubermatic Kubernetes Platform’s monitoring stack in future releases, helping cluster operators plan according to their projected needs. Due to our separate clusters the Grafana dashboards do not yet have access to the Prow-internal metrics. We plan on installing a dedicated Prometheus instance into the control plane cluster and federate the data over into the worker cluster, as we still like the approach of having a monitoring setup in the “less privileged” cluster. The existing metrics can also be used to define proper, actionable alerts, for example when the job queue size for an organisation or repository exceeds a certain threshold. The metrics could also be used for triggering custom auto scaling solutions if needed. Thanks to setting proper resource requests and having pods actually be pending, existing cluster autoscalers like that on Google’s Kubernetes Engine (GKE) can easily be triggered to accommodate increased usage. --- ## Lowering Maintenance Overhead of Managing Kubernetes - **URL:** https://www.kubermatic.com/customers/syseleven/ - **Date:** 2026-06-23 - **Description:** Find out why SysEleven chose to partner with Kubermatic to create MetaKube, a white label of the Kubermatic Kubernetes Platform. # SysEleven Lowers Maintenance Overhead of Managing Kubernetes ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) ![Basketball](/static/pexels-pixabay-163452_hu_8f0009d642571863.jpg) ![Logo SysEleven](/static/syseleven_xl_logo_quer_rgb_neg-1-.png) ## About SysEleven SysEleven provides IT infrastructure services for corporate environments. It provides clients with managed hosting solutions to their website, private cloud storage, server management, database management, and other related services. Customers began to approach SysEleven about running containers and using container orchestration. To offer their customers the highest quality services for which they are known, they sought an easy to use container orchestration solution. SysEleven chose to partner with Kubermatic to create MetaKube, a white label of the Kubermatic Kubernetes Platform, giving their customers Kubernetes clusters in one click. Simon Pearce, MetaKube Team Lead and Systems Architect at SysEleven, explains why they chose Kubermatic Kubernetes Platform to run Kubernetes in their data centers. ![Icon globe](/images/icons/people.svg) ### 110+ employees worldwide ![Icon graph chart](/images/icons/graph-chart.svg) ### 450+ customers ![Icon business case](/images/icons/cloud.svg) ### 14+ years on the market ![Double quotes image](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==) Before KKP, we had to admit that applications and servers scale well but staff wouldn’t: with every 10th new customer, we needed a new member of staff as an engineer. With Kubermatic Kubernetes Platform we are beginning to change that model. We get rid of toil work and by that give our engineers time to focus on improving our products. Simon Pearce, MetaKube Team Lead and Systems Architect at SysEleven ![Simon Pearce](/static/simon-pearce_syseleven_black-and-white_hu_2c8867b276ac8a76.png) [Read the Full Story](/static/Customer%20Success%20Story_SysEleven_Custom%20Page.pdf) --- ## Best Practices #4: Auto Backup & Disaster Recovery - **URL:** https://www.kubermatic.com/blog/cloud-native-best-practies-4/ - **Date:** 2026-05-07 - **Description:** Automatic backup and disaster recovery are key to providing a more resilient customer service with fast time to recovery which reduces lost revenue. - **Categories:** Best Practices - **Tags:** KKP, Kubernetes - **Authors:** Bill Mulligan To [quote Michael Dell](https://www.forbes.com/sites/richkarlgaard/2017/08/08/how-michael-dell-reinvented-his-company/?linkId=40742788#208a6a9548a7), “the cloud isn’t a place, it’s a way of doing IT.“ As IT becomes more and more central to what every company does, understanding cloud native best practices is key not only for the IT department – but for every part of a business. <br> This post is the fourth of a seven-part series examining how cloud native can help businesses deliver on their promise of better, faster, cheaper. This part explains how automatic backup and disaster recovery are key to providing a better, **more resilient service** to customers with a **fast time to recovery** which **reduces lost revenue** when disaster strikes. #### Cloud Native Best Practices: Automatic Backup and Disaster Recovery Gone are the days where backup meant pressing hard to get the carbon copy triplicate. Today, most business information – and value – lies on computer servers rather than paper. In this digital age, the business impact of IT failures and outages can almost not be overstated. The average cost of IT downtime is [$336,000 per hour](https://blogs.gartner.com/andrew-lerner/2014/07/16/the-cost-of-downtime/) and 93% of companies that lose a data center for 10 days or more will go out of business in the next year. As IT departments become the core around which every other department operates, for business continuity, it is imperative that IT departments have effective plans in place to automatically backup systems and recover when disaster strikes. Taking a cloud native approach to IT can reduce costs and operational overhead. However, without proper disaster recovery in place too, all of these gains can be quickly erased. Setting up an effective recovery process for when outages occur is a three-step process. First, each part of the IT system must be interchangeable and replaceable (see part two of this series [Pets vs. Cattle](/blog/cloud-native-best-practices-2-why-cattle-not-pets/) for a full explanation). Second, there needs to be automatic snapshots and backups of systems so a replacement copy is ready to go whenever a problem occurs. Finally, a recovery process from these backups needs to be established and practiced. Modern IT environments have many moving parts making it extremely easy to miss a piece during backup and recovery. Automation and a practiced plan are key to having a successful process that ensures business continuity. Automation can help avoid manual mistakes, ensure important steps are not overlooked, and speed up the whole process. When something does go wrong, besides the backup copy, there also needs to be a practiced plan to fix and/or replace the broken system. Even for companies that do have backups, 75% were not able to restore all of their lost data, with 23% unable to recover [any data at all.](https://www.ontrack.com/resources/press/details/63920/kroll-ontrack-research-one-third-of-companies/) Disaster recovery planning – and testing – are critical to verify that recovery systems actually work and ensure business continuity. For cloud native businesses, building backup and recovery of Kubernetes clusters is key. However, Kubernetes itself comes with no out-of-the-box mechanisms for this critical business need. [Project Velero](https://velero.io/) (originally Heptio Ark) was created as an open source tool to safely backup, restore, and perform disaster recovery for Kubernetes cluster resources and persistent volumes – filling this serious business gap. Project Velero allows users to automatically schedule Kubernetes cluster backups, replicate and test them across cloud providers, and restore them in case of loss. Velero has seen widespread adoption across the Kubernetes ecosystem with support for all the major cloud providers with Digital Ocean even providing their [own documentation.](https://www.digitalocean.com/community/tutorials/how-to-back-up-and-restore-a-kubernetes-cluster-on-digitalocean-using-heptio-ark) When we designed Kubermatic Kubernetes Platform, we knew every business we work with needs backups and disaster recovery built into their Kubernetes infrastructure. We chose to use Project Velero because it is the best in class open source tool for managing backup and disaster recovery of Kubernetes cluster resources and persistent volumes. We built [Kubermatic Kubernetes Platform](https://kubermatic.io/) with an out-of-the-box integration of Project Velero to give our customers the best tools to minimize disaster impact, allowing our customers to create **a more reliable service with faster time to recovery** ensuring they don’t **lose revenue** due to extended system outages. Check out part five: API driven architecture to understand how to design a best in class production system. --- ## Running HA Kubernetes clusters on AWS using KubeOne - **URL:** https://www.kubermatic.com/blog/running-ha-kubernetes-clusters-on-aws-using-kubeone/ - **Date:** 2026-05-27 - **Description:** Learn step-by-step how to deploy and run a vanilla cluster with machine-controller and metrics-server on AWS and other providers. - **Categories:** Products, Community - **Tags:** KubeOne, Open Source Projects - **Authors:** Alexander Sowitzki In a previous [blog post](/blog/kubeone-simplified-lifecycle-management-for-ha-kubernetes-clusters/), we talked about KubeOne and how it makes your highly available Kubernetes cluster easier to manage. In this post, I'll show you step-by-step how to deploy and run a vanilla cluster with machine-controller and metrics-server on AWS. You may also adapt this process to other [providers](https://github.com/kubermatic/kubeone/tree/master/docs) since it differs only marginally. #### Creating your first cluster In this example we use [Terraform](https://www.terraform.io/) to create the infrastructure. Of course KubeOne can also be configured using Ansible or manually. We will need to run through the following steps: * Get KubeOne and Terraform * Create infrastructure * Create configuration file * Install your cluster using KubeOne * Enjoy and have fun If this sounds like much effort: Don’t worry, we have taken care of many steps for you. Expect about 20 minutes of your time for these steps. #### How to AWS? Let’s say you just have access to Amazon Web Services (AWS) and you want to get started, go ahead and grab the latest release on our [releases page](https://github.com/kubermatic/kubeone/releases/latest). We support KubeOne on Linux and MacOS. #### Installing Starting with v0.10.0-alpha.0, our release archive contains the KubeOne binary and example Terraform scripts that can create the infrastructure for you. If you want to use an earlier version you may find the examples in our [GitHub repository.](https://github.com/kubermatic/kubeone) If you got a distribution with up to date package repositories you can fetch Terraform that way, otherwise follow their [installation guide](https://learn.hashicorp.com/terraform/getting-started/install.html) (Take at least version 0.12.0). #### Terraforming Next up, we’ll configure Terraform and create the infrastructure where we’ll run Kubernetes. Inside the KubeOne repository, head into the examples/terraform/aws directory. Here you’ll find a Terraform scripts you can use to get started. First, fetch the required Terraform modules using the following command: ```bash terraform init ``` If you don’t need anything too fancy, you don’t need to touch the existing files here. You just need to create a file named `terraform.tfvars` that contains basic information on how your cluster should be shaped: ```bash cluster_name = "alexbox" aws_region = "eu-central-1" worker_os = "ubuntu" ssh_public_key_file = "~/.ssh/id_rsa.pub" ``` This sets the name of the new cluster, the region where nodes will reside in and the flavor of the worker nodes. I chose the region of Central Europe (since I live here and want short latencies) and Ubuntu for control plane and worker nodes. By default a single worker node is created initially. Terraform will copy your public SSH key to created hosts so you can access them. Make sure that it is present at the configured location. There are more options you can customize, just take a look into `variables.tf` for a list of variables. To tell Terraform and KubeOne how to authenticate, export your credentials (note that the first character of the command line is a space, which prevents your credentials from popping up in your bash history): ```bash $ export AWS_ACCESS_KEY_ID=' 🔒🔒🔒' AWS_SECRET_ACCESS_KEY='🔒🔒🔒' ``` This credentials are also deployed on the cluster so tools like machine-controller can autoscale your cluster. If you want to customize the initial infrastructure state even more , e.g. increase the amount of worker nodes, you can edit the `output.tf` file accordingly. Finally, create you infrastructure using: ```bash terraform apply ``` Now that our infrastructure is in place, in comes KubeOne, which will set up the cluster for us. #### Deploy your K8s high up in the clouds Now you have some barren VMs that need to be populated with your hopes and dreams, mainly the Kubernetes control plane. Use the following command to generate a KubeOne configuration file: ```bash $ kubeone config print > config.yaml ``` In our case, the configuration contains the kubernetes version to install and which cloud provider to use. The rest is taken over from the Terraform configuration: ```bash apiVersion: kubeone.io/v1alpha1 kind: KubeOneCluster name: alexbox versions: kubernetes: 1.14.1 cloudProvider: name: aws ``` The basic KubeOne configuration file defines what Kubernetes version will be used and on what provider we’re deploying on. The configuration file has many more options and features and if you want to customize them, get the full config file with ```bash $ kubeone config print --full > config.yaml ``` The cluster provisioning is done by supplying the `install` command with the config file and the Terraform state. ```bash $ kubeone install config.yaml -t . ``` #### Using your newly created cluster And now that the cluster provisioning is done, you can use your new cluster. KubeOne even dropped the kubeconfig file for your. Just export its location as an environment variable with: ```bash $ export KUBECONFIG=$PWD/alexbox-kubeconfig ``` You are ready to `kubectl` around as you like. For example, try out to list nodes of the new cluster: ```bash $ kubectl get nodes ``` #### Scaling your cluster KubeOne installs a vanilla cluster with a couple of open source projects, such as [machine-controller](https://github.com/kubermatic/machine-controller), for automatically managing the cluster using Cluster-API and [metrics-server.](https://github.com/kubernetes-incubator/metrics-server) Machine-controller makes it easy to scale your cluster on demand. Execute the following to get all MachineDeployments in your new cluster: ```bash kubectl --kubeconfig=alexbox-kubeconfig get -n kube-system machinedeployment ``` The result should be something like this: ```bash NAME REPLICAS PROVIDER OS KUBELET AGE alexbox-pool1 1 aws ubuntu 1.14.1 3m44s ``` To increase the number of worker nodes to three just scale the machine deployment up: ```bash kubectl scale -n kube-system machinedeployment/alexbox-pool1 --replicas=3 ``` **Note:** There is currently a [bug](https://github.com/kubermatic/kubeone/issues/593) with Kubernetes 1.15 requiring you to provide the resource version when using the `scale` command. This version can be obtained using `kubectl describe`. Of course you can also configure to opt-out of machine-controller but you would have to take care of worker nodes by yourself. #### Conclusion As you can see, the happy path of KubeOne makes bootstrapping a cluster much more automated, less error prone and (almost) fun to do. KubeOne works out-of-the-box with a bunch of other cloud providers including Google Cloud, Packet and DigitalOcean. You can even install a cluster on premise with OpenStack, VMware vSphere or completely bare metal if you are adventurous. See our [docs](https://github.com/kubermatic/kubeone/tree/master/docs) for more information, take a look at our latest [webinar](https://www.youtube.com/watch?v=JDc048_7OdI&feature=youtu.be) or the [technical deep-dive talk](https://www.youtube.com/watch?v=AYR7TRV-JMo) that was recorded on the [ContainerDays 2019.](https://www.containerdays.io) --- ## Announcing Kubermatic Kubernetes Platform 2.11 - **URL:** https://www.kubermatic.com/blog/announcing-kubermatic-kubernetes-platform-2-11/ - **Date:** 2026-05-07 - **Description:** The latest 2.11 release comes with native support of two more cloud providers and improved DevOps experience with new service accounts. - **Categories:** Products - **Tags:** KKP - **Authors:** Kristin Wittig The world doesn’t stand still and we don’t either. We are constantly working on improving and optimizing Kubermatic Kubernetes Platform, our enterprise-grade Kubernetes Management Platform for any infrastructure. After three months of development time, we are proud to announce availability of Kubermatic Kubernetes Platform 2.11. #### New providers for enhanced freedom of choice With the latest release, we now provide support for two more cloud provider: Google Cloud Platform and Packet. This allows our customers to deploy fully Kubermatic Kubernetes Platform-managed clusters on GCP and Packet at the click of a button. #### Improved DevOps experience with new service accounts With Kubermatic Kubernetes Platform 2.11, we are happy to introduce service accounts. Service accounts allow you to seamlessly authenticate any application with the Kubermatic Kubernetes Platform API, so it can run automated API requests on your behalf. This delivers an easy way to set up infrastructure-as-a-code scenarios in a truly cloud native way. #### Always run the latest Kubernetes version Kubermatic Kubernetes Platform now supports Kubernetes 1.15. With Kubermatic Kubernetes Platform you can freely choose which Kubernetes version you want to run. <br> For more information, see the changelog here: [https://docs.kubermatic.io/changelog/2.11/](https://docs.kubermatic.io/changelog/2.11/) --- ## Cloud Native Best Practices #3: Open Source - **URL:** https://www.kubermatic.com/blog/cloud-native-best-practices-3-open-source/ - **Date:** 2026-05-07 - **Description:** Enterprises embracing Open Source create better technology at lower cost while speeding up software development and new employee on-boarding. - **Categories:** Best Practices - **Tags:** Kubernetes, Open Source Projects - **Authors:** Bill Mulligan [To quote Michael Dell,](https://www.forbes.com/sites/richkarlgaard/2017/08/08/how-michael-dell-reinvented-his-company/?linkId=40742788#208a6a9548a7) "the cloud isn’t a place, it’s a way of doing IT." As IT becomes more and more central to what every company does, understanding cloud native best practices is key not only for developers – but for every part of a business. This blog is the third of a seven-part series providing a roadmap to help teams build the business case for a cloud native IT approach. This post examines the business side of using free and open source software (FOSS) to build a cloud native stack. While many companies traditionally shunned FOSS, they are now finding themselves falling behind competitors that have adopted it. Enterprises embracing FOSS can create **better technology** at a **lower cost** while **speeding up** software development and new employee on-boarding. Finally, the vibrate both end-user and vendor community around open source cloud native technologies has created an enterprise-ready ecosystem that allows companies to find the exact type of help they need. #### Cloud Native Best Practices: Open Source To many business people, the idea that something you can get for free is worth billions of dollars seems to be almost heresy. Yet that is exactly what the open source software ecosystem represents. The [Linux Foundation estimates](https://www.linuxfoundation.org/infographic/2015/09/estimating-the-total-development-cost-of-linux-foundations-collaborative-projects/) that it would cost over $5 billion to develop the 115,013,302 lines of code freely available in only its collaborative projects. Quickly disappearing are the days where vendors locked customers into their software while FOSS was limited to people hacking away in their free time. FOSS runs in almost every piece of technology we use today: from [our phones to big data analysis tools](https://www.forbes.com/sites/paulnoelguely/2018/09/03/open-source-software-from-the-periphery-of-tech-to-the-mainstream-of-finance/#505abdd469ab) and many projects receive both cash and code from large tech companies. FOSS, like Linux and Kubernetes, have gained such wide adoption because of the power it gives to both the business and tech sides of companies. On the business side, using open source software reduces the cost of creating high-quality software stacks, simplifies recruiting, and shortens employee on-boarding time. By adopting open source software, [Virgin Mobile](https://www.infoworld.com/article/2631374/open-source-software/open-source-s-transitional-phase.html) recently reported that they saved 80% of their software development costs. Many businesses also require enterprise-level support for the products they choose to put into critical services so they have someone to call when the system breaks at 3 am. The open source ecosystem creates room for multiple vendors to offer support for the same technology, letting companies have the necessary support without being locked into one vendor and vendor lock-in’s associated high prices. For employee costs, many open source projects enjoy widespread use and knowledge bases thus companies using these technologies find it easier to [recruit and onboard employees](https://opensource.google.com/docs/why/) from the pool of contributors and/or users. It is also simpler to onboard employees to a company since they will already have familiarity with how the open source parts of the stack work. On the tech side, using and contributing to open source software can [help companies produce better software.](https://opensource.google.com/docs/why/) Rather than having to build everything from scratch, companies can instead leverage the work of other companies trying to solve the same or similar problems, whether that be building a web application or [securing software stacks.](https://www.pcworld.com/article/202452/why_linux_is_more_secure_than_windows.html) With so many people looking over a code base, open source software has also been found to be [similar or higher quality](https://techcrunch.com/2012/02/23/with-many-eyeballs-all-bugs-are-shallow/?guccounter=1&guce_referrer_us=aHR0cHM6Ly90eXBvMy5jb20vYmxvZy9wcm9zLWNvbnMtb2Ytb3Blbi1zb3VyY2Utc29mdHdhcmUtYXQtdGhlLWVudGVycHJpc2UtbGV2ZWw_dXRtX21lZGl1bT1UWVBPMyUyMEJsb2cmdXRtX3NvdXJjZT1CbG9nJTIwUG9zdCUyMC0lMjBQcm9zJTIwJTI2JTIwY29ucyUyMG9mJTIwb3Blbi1zb3VyY2UlMjBzb2Z0d2FyZSUyMGF0JTIwdGhlJTIwZW50ZXJwcmlzZSUyMGxldmVsJnV0bV9jYW1wYWlnbj1PcGVuJTIwU291cmNlJTIwQ01T&guce_referrer_cs=V_x28qHF69K7JQnFfmfHTg) than proprietary software. Leveraging open source software gives companies access to better software. At Kubermatic, we strongly believe in being part of the open source community. We actively work on upstream Kubernetes, with many contributions to the [Cluster Lifecycle SIG](https://github.com/kubernetes/community/tree/master/sig-cluster-lifecycle) and the [Kubernetes Dashboard](https://github.com/kubernetes/dashboard) among others. In addition, we have open sourced some of our internal projects like [KubeOne](https://github.com/kubermatic/kubeone), Sponson, [machine-controller](https://github.com/kubermatic/machine-controller), and KubeCI. We also built Kubermatic Kubernetes Platform Container Engine to align as closely as possible with upstream Kubernetes principles and run pure vanilla Kubernetes clusters rather than creating our own fork. At the core of Kubermatic Kubernetes Platform are Kubernetes Operators and Custom Resource Definitions. Since this is how most open source extensions of Kubernetes function, it makes it easier for our customers to run, manage, and update Kubermatic Kubernetes Platform managed clusters and find employees knowledgeable enough to manage their Kubernetes infrastructure. Open source technology, with Kubernetes at the core, is the standard for cloud native IT. It gives companies better software at a lower cost while simultaneously enabling them to speed up software development and employee onboarding. For this reason, open source technology should be at the center of every cloud native business strategy. Learn how to ensure business continuity in the cloud in our upcoming part four on automatic backup and disaster recovery. --- ## ContainerDays 2019: 3 Years of Container Craziness - **URL:** https://www.kubermatic.com/blog/containerdays-2019-3-years-of-continued-container-craziness/ - **Date:** 2026-05-07 - **Description:** Over 1,000 attendees came from around the world to the Hamburg Harbor Museum to discuss the future of Kubernetes and cloud native technologies. - **Categories:** Community - **Tags:** Events, Open Source Projects - **Authors:** Bill Mulligan In 2016, when we first launched ContainerDays, Docker was THE hot technology and Kubernetes had barely reached release 1.3. We felt that something special was shaping up in the cloud native ecosystem, but it was still very much unclear who the winner would be. Docker Swarm vs. Mesos vs. Kubernetes was a widely debated topic back then. After traveling around Germany from one Meetup to the other for months, we felt the need to bring together the container community in one place to share their insights, experiences, and ideas. But….that’s a lot easier said than done. Why would anyone believe (and invest) in some guys in funny squid t-shirts insisting that containers are the future of IT infrastructure and a central conference is a fruitful idea? Many, many phone calls and sleepless nights later, we were lucky to have 1&1, Nexinto (today: PlusServer), Google, and CoreOS (today RedHat) supporting this idea. In the end, we were able to gather 220 participants and many great speakers in the harbor of Hamburg to discuss the containerization of the IT industry. And so the story began... <br> <img src="/images/blog/2019-07-04/image2.jpg" alt="Beginning" width="100%"/> <br> <img src="/images/blog/2019-07-04/image3.jpg" alt="Beginning-2" width="100%"/> <br> Three years on, it is hard to believe how far and fast the cloud native ecosystem has come. While many things have changed, a few things have become more clear: Kubernetes is the future of IT infrastructure and ContainerDays will continue to be the place to be to discuss and define this future. With this history in mind, we wanted the fourth edition of ContainerDays to be the best one yet and it certainly delivered. Over 1,000 attendees came from around the world to the Hamburg Harbor Museum to consider cloud native technologies. Day one kicked off with a variety of workshops ranging from Kubernetes 101 to securing container delivery with open source tools. From onboarding beginners to creating a hardened enterprise ready stack, this breadth highlights the strength of the cloud native ecosystem. The Kubermatic crew ended the first day in three different locations. Some participated in our pre-conference Meetup at PlusServer where Matthias Heussler and Thorsten Jakoby talked about moving legacy systems into more cloud native environments, our speakers joined the Speakers Dinner at the riverside Strand Pauli, and the rest joined our partners and friends from SysEleven on the Feuerschiff. Day two kicked off bright, early, and hot. In the welcoming words of our CEO Sebastian, 33 degrees and sunny is “typical Hamburg weather.” (Big shout out to the events team for keeping the water and Club Mate well stocked throughout the whole event) Keynotes by Ihor Dvoretskyi from the CNCF and Craig McLuckie from VMware shone the spotlight on the growth and strength of the Kubernetes community. The next two days were a whirlwind of talks, sunshine, food trucks, and great discussions about where cloud native will head next. While most of the talks were developer focused, what really struck us about them is that they went far beyond just containers and Kubernetes. Zach Arnold spoke about IT security meeting financial services industry standards while Guy Salton focused on using Helm to actually deploy applications. (Also shout out to Henning Jacobs for jumping in and giving an extra talk when one speaker didn’t make it) For us, this transition is indicative of larger trends within the industry. The question is no longer about “IF” containers and Kubernetes should be used, like at the first edition of ContainerDays. The question is now “HOW” do we best use them and “WHAT” extra tooling do we need. Beyond the conference, ContainerDays also presented the perfect opportunity for all Loodsies to come together as a team to catch up with colleagues, greet new team members, and meet potential new hires. As a remote team, it can sometimes be hard to see how the teams grows, but bringing everyone together into one place really put it into perspective. We’re all guessing how many people we will have to try to fit into the photo next year. Since the first ContainerDays three years ago, we have been on an exciting journey shaping the future of IT infrastructure. Now that containers and Kubernetes are here to stay, the fun part is seeing all the new possibilities open up. While we don’t have a crystal ball to predict exactly what the future will hold, you can bet it will be discussed and debated at ContainerDays. We can’t wait to see what the next years will bring! <br> **Learn more** * [All CDS recordings](https://www.youtube.com/channel/UCi1CejrHbE6QPz37dG9gMFA) <br> <img src="/images/blog/2019-07-04/image4.jpg" alt="Sebastian-loodse" width="100%"/> <br> <img src="/images/blog/2019-07-04/image6.jpg" alt="Octo-Kubermatic" width="100%"/> --- ## Cloud Native Best Practices #2: Why Cattle, not Pets - **URL:** https://www.kubermatic.com/blog/cloud-native-best-practices-2-why-cattle-not-pets/ - **Date:** 2026-05-07 - **Description:** Learn about the Pets vs Cattle analogy and how it can help business provide a better service with faster time to recovery which reduces lost revenue. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Bill Mulligan To [quote Michael Dell](https://www.forbes.com/sites/richkarlgaard/2017/08/08/how-michael-dell-reinvented-his-company/?linkId=40742788#208a6a9548a7), “the cloud isn’t a place, it’s a way of doing IT.” As IT becomes more and more central to what every company does, understanding cloud native best practices is key not only for developers but for every part of a business. This post is the second of a seven-part series examining how cloud native best practices can help businesses deliver value to their customers better, faster, and cheaper. This part explains the Pets vs Cattle analogy and how it can help business provide a **better service** with **faster time to recovery** which **reduces lost revenue.** #### History: Pets vs Cattle The analogy of *Pets vs Cattle* has become one of the core concepts of a DevOps service model. The idea was first introduced by Bill Baker, a distinguished Engineer at Microsoft, in his presentation “[Scaling SQL Server 2012](http://www.pass.org/eventdownload.aspx?suid=1902)” and later popularized by Gavin McCance talking about the [OpenStack cloud at CERN.](https://www.slideshare.net/gmccance/cern-data-centre-evolution) The difference between Cattle and Pets is how vital each individual is to you. To pull from [Randy Bias’](http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/) post on the history of this analogy: *In the old way of doing things, we treat our servers like Pets, for example, Bob the mail server. If Bob goes down, it’s all hands on deck. The CEO can’t get his email and it’s the end of the world. In the new way, servers are numbered, like Cattle in a herd. For example, www001 to www100. When one server goes down, it’s taken out back, shot, and replaced on the line.* Pets are each vitally important, but Cattle are interchangeable. Moving production software infrastructure from Pets towards Cattle is key to creating a highly available (HA) system with reduced failures, a smaller blast radius, and faster disaster recovery. Taken together, moving towards a Cattle service model helps businesses deliver a better service with reduced downtime. #### Cloud Native Best Practices: Pets vs Cattle Reliably running and managing scalable IT infrastructure necessitates using Cattle and Kubernetes clusters will be no different. [Joaquin Menchaca’s blog](https://medium.com/@Joachim8675309/devops-concepts-pets-vs-cattle-2380b5aab313) nicely traces the evolution from a Pet to Cattle management model up the stack from bare metal servers to cloud native containers and container orchestrators. At each stage, a higher layer of the stack becomes replaceable creating [immutable production](https://www.digitalocean.com/community/tutorials/what-is-immutable-infrastructure) where only exact copies are deployed and they can be replaced at anytime. If anything needs to be changed, a new deployment is made and the old ones are decommissioned. Immutable production eliminates variations leading to fewer deployment failures, consistency across environments, easy horizontal scaling, and a simple rollback and recovery process. To take advantage of these benefits and bring immutable containers into production, Kubernetes has become the de facto standard because it simplifies the process of deploying and orchestrating containers. However, installing, managing, and updating Kubernetes itself is no simple undertaking. To avoid these challenges, clusters have become the new Pets with companies running a few large vital clusters rather than multiple smaller replaceable clusters. This is in direct contradiction to the cloud native principles Kubernetes was founded on. To derive the full value from a cloud native approach, it is imperative that companies treat their Kubernetes clusters like Cattle too. Spinning them up and down on demand and treating them as disposable, replaceable assets rather than prized Pets. Beyond easing management and saving operations time and money, running Kubernetes clusters as Cattle can have a real impact on the bottom line too. For example, an e-commerce company earning 5 billion euros per year is completely dependent on their shop being online. Every minute of production outage is 10,000 Euros in missed sales. In a case study with the CNCF, when VSCO standardized their provisioning and outage recovery with Kubernetes, they **reduced their outage time by 88%.** The Cloud Native Computing Foundation is already seeing businesses transition towards using Kubernetes clusters like Cattle. [In the past six months](https://www.cncf.io/blog/2018/11/13/cncf-survey-china-november-2018/), organizations running 1-5 production clusters decreased 37%, while organizations running 11-50 clusters increased 154%. Treating infrastructure as Cattle allows companies to simply replace their infrastructure and come back online sooner, saving sales. At Kubermatic, we strongly believe in treating Kubernetes clusters as Cattle. We use multiple tools to make it as easy as possible for our developers and operators to create and use Kubernetes clusters including [kind](https://github.com/kubernetes-sigs/kind) and [KubeOne](https://github.com/kubermatic/kubeone), and [Kubermatic Kubernetes Platform](/products/kubermatic-kubernetes-platform/). We use kind to quickly spawn Kubernetes clusters to run integration and E2E tests in our CI/CD pipeline. We recently open sourced KubeOne because it gives developers the ability to quickly install, manage, and upgrade highly available Kubernetes clusters on any cloud provider, on-prem, or bare-metal cluster. Furthermore, we are actively contributing to [cluster-api](https://github.com/kubernetes-sigs/cluster-api) in upstream Kubernetes to simplify the process of cluster creation, configuration, and management. Finally, when we designed Kubermatic Kubernetes Platform for large-scale installations, we followed this best practice of turing clusters into Cattle, too. This requires that creating, updating, and deleting a Kubernetes cluster is only one click away for anyone. Kubermatic Kubernetes Platform does this by spinning up the user cluster Kubernetes control components as containers in the seed Kubernetes cluster ([architecture details here](https://docs.kubermatic.io/concepts/architecture/)). If anything happens to a control component of the worker cluster, it will be **automatically restarted and replaced** by the seed Kubernetes cluster turning the control components and cluster itself into cattle. #### Conclusion Running Cattle rather than Pets is a computing infrastructure best practice no matter what layer of the stack. It provides customers a better service, reduces time to recovery, and eliminates lost revenue from production outages. Kubernetes became the standard for container orchestration because it allows you to treat your containers like Cattle. Kubernetes clusters themselves should be treated like Cattle too. --- ## KubeCon Barcelona Recap - **URL:** https://www.kubermatic.com/blog/kubecon-barcelona-recap/ - **Date:** 2026-05-07 - **Description:** We had a great week with sunshine, tapas, beaches, sangria, and 8,000 of our Kubernetes friends. - **Categories:** Company - **Tags:** KubeOne, Events, Announcements - **Authors:** Bill Mulligan Barcelona – sunshine, tapas, beaches, sangria, and 8,000 of your closest Kubernetes friends. Since KubeCon Seattle in December, the explosive growth of the cloud native community has only continued with KubeCon Barcelona becoming one of the largest open source conferences ever hosted in Europe. With so many events and announcements around KubeCon, we thought it would be the perfect time and place to host a Kubermatic wide gathering to soak in the new community developments and catch up with one another. We went by train, plane, and car to bring the whole company together in Barcelona. <br> <img src="/images/blog/2019-06-10/image1.jpg" alt="Team" width="100%"/> <br> Impatient as we are for anything cloud native, we kicked off our KubeCon activities already the weekend before. Hendrik and Alvaro headed to the first <a href="https://cloud-native.rejekts.io/">Cloud Native Rejects</a> hosted by the great folks at <a href="https://kinvolk.io/">Kinvolk</a>. This event gave some great speakers who didn’t get a spot at KubeCon a chance to present their ideas. Meanwhile, Julian, Sebastian, and Bill organized the first meeting of Kubernetes SIG-Bike. On the first day, Bill set the request for a 60 km flatish ride but unfortunately forgot to set the limit which thus turned into 90 kms with more than a couple of hills. Luckily, this production error was fixed for the second day. Still, you could hear Julian and Sebastian complaining about their sore muscles for the next two days:-) <br> <img src="/images/blog/2019-06-10/image2.jpg" alt="SIG-Bike" width="100%"/> <br> Monday was a full day of sightseeing and co-located events. Half the team headed into Barcelona to see La Sagrada Familia and Park Güell while the other half went to the Openshift Commons Gathering and Cloud Native Network Services Day hosted by <a href="/blog/we-are-happy-to-support-lf-networking/">LFN</a>. Day one of KubeCon kicked off with a keynote from our very own Nikhita about “Getting Started in the Kubernetes Community”. Wow! If you have thought about becoming a Kubernetes contributor, but don’t know how, check out her talk to find out! Besides the keynote, Sebastian #1 spoke with Simon from SysEleven about Kubernetes Security and How to Fix Kubernetes Cluster at Scale, Sebastian #2 co-presented the Deep Dive: Kubernetes (UI) SIG, and Nikhita was on a panel about becoming a Kubernetes Contributor. We’re so proud that so many of our talks were chosen from among the thousands of speaker submissions. On top of that, Artiom and Marko gave demos of our recently released <a href="https://github.com/kubermatic/kubeone">KubeOne</a> at the Kubermatic booth. <br> <img src="/images/blog/2019-06-10/image3.jpg" alt="Artiom and Marko" width="100%"/> <br> Outside the convention center (after walking for kilometers to get out), Barcelona provided the perfect city to come together as a team. Tapas and sangria were both flowing freely at our company dinners and Sebastian almost met his perfect match with a steak. All in all, KubeCon Barcelona was a great time to come together as a company and we’re even more excited for next year after it was announced it will be almost in our backyard in Amsterdam. #### Where to learn more <a href="https://www.youtube.com/watch?v=Bho4miiByP0&list=PLytD1l2uNPnyGx8CpwvDUkGmDUz1aOEtV&index=2&t=71s" target="_blank">Keynote: Getting Started in the Kubernetes Community </a> <a href="https://www.youtube.com/watch?v=5dWRh301Lno&list=PLytD1l2uNPnyGx8CpwvDUkGmDUz1aOEtV&index=3&t=0s" target="_blank">Talk: Kubernetes Security and How to Fix K8s Cluster at Scale </a> <a href="https://www.youtube.com/watch?v=KRXKULN0QXU&list=PLytD1l2uNPnyGx8CpwvDUkGmDUz1aOEtV&index=4&t=0s" target="_blank">Panel Discussion: From User to Member: Becoming a Kubernetes Contributor </a> <a href="https://www.youtube.com/watch?v=kO_f4AvLvyU&list=PLytD1l2uNPnyGx8CpwvDUkGmDUz1aOEtV&index=5&t=0s" target="_blank"> Deep Dive: Kubernetes (UI) SIG </a> <a href="https://www.cncf.io/community/webinars/meet-kubeone-an-open-source-cluster-lifecycle-and-operations-tool-for-ha-kubernetes/" target="_blank">KubeOne CNCF Webinar </a> <br> <img src="/images/blog/2019-06-10/image4.jpg" alt="Backyard" width="100%"/> <img src="/images/blog/2019-06-10/image5.jpg" alt="Steak" width="100%"/> --- ## We Are Excited to Kick Off the MELLODDY Project - **URL:** https://www.kubermatic.com/blog/we-are-excited-to-be-in-the-consortium-kicking-off-melloddy/ - **Date:** 2026-05-07 - **Description:** The new research consortium seeks to accelerate drug discovery using machine learning to unlock maximum potential of pharma industry data. - **Categories:** Company - **Tags:** Announcements - **Authors:** Kristin Wittig **The new research consortium seeks to accelerate drug discovery using machine learning to unlock maximum potential of pharma industry data. The project aims to leverage the world’s largest collection of small molecules with known biochemical or cellular activity to enable more accurate predictive models and increase efficiencies in drug discovery.** A new consortium of pharmaceutical, technology and academic partners has announced the launch of the "MELLODDY" (**M**achine **L**earning **L**edger **O**rchestration for **D**rug **D**iscovery) project which aims, for the first time, to use machine learning methods on the chemical libraries of 10 pharma companies and to develop a platform creating more accurate models to predict which compounds could be promising in the later stages of drug discovery and development. The project, which demonstrates a new model of collaboration between traditional competitors in drug discovery, involves an unprecedented volume of competitive data. Through MELLODDY, a sophisticated platform is being developed that addresses at the same time the need for security and privacy preservation while allowing for enough information exchange to boost predictive performance. The project involves 17 partners from across Europe and receives funding from the Innovative Medicines Initiative (IMI) as a public-private partnership. Janssen Pharmaceutica NV, one of the Pharmaceutical Companies of Johnson & Johnson, is the pharmaceutical industry lead of the project with coordination provided by Owkin. The project will operate for three years, concluding in June 2022, with an estimated budget of €18,4 million. "The MELLODDY project is a groundbreaking collaboration that has the potential to accelerate drug discovery and improve patient outcomes by enabling, for the first time, research to be conducted across the consortium’s decentralised and highly proprietary databases of annotated chemical libraries," said Hugo Ceulemans, MELLODDY Project Leader and Scientific Director, Discovery Data Sciences at Janssen Pharmaceutica NV. "This project allows the pharma partners for the first time to collaborate in their core competitive space, invigorating discovery efforts through efficiency gains." "The MELLODDY consortium will use Owkin’s block-chain architecture technology to extract insight from multiple datasets without having to first pool the data," said Mathieu Galtier, Project Coordinator, Owkin. "The goal is to harness the collective knowledge of the consortium in a platform containing amongst others multi-task predictive machine learning algorithms incorporating an extended privacy management system, to identify the most effective compounds for drug development, while protecting the intellectual property rights of the consortium contributors. We are excited to be part of this bold, federated learning research revolution." #### About the MELLODDY Project MELLODDY aims to train machine learning models across multi-partner datasets while ensuring privacy preservation of both the data and the models by developing a platform using federated learning. The MELLODDY platform uses Amazon Web Services technologies in order to execute Machine Learning algorithms from academic partners on a large scale. The data never leaves the owner’s infrastructure and only non-sensitive models are exchanged. A central dispatcher allows each partner to share a common model to be consolidated collectively. To provide full traceability of the operations, the platform is based on a private blockchain. This means that a ledger will be distributed across all contributing pharma partners in such a way that there is no central authority. The platform guarantees by design that partners keep control and visibility over their own private data. Since there is no central authority, any communication between the dispatcher and a ledger needs to be approved by all partners before one can proceed. Like a bank statement, the ledger holds a log of all activities and can be requested after a federated run. The MELLODDY platform is designed to prevent the leaking of proprietary information from one data set to another or through one model to another while at the same time boosting the predictive performance and applicability domain of the models by leveraging all available data. The MELLODDY consortium consists of 17 partners: <br> * 10 pharmaceutical companies: Amgen, Astellas, AstraZeneca, Bayer, Boehringer Ingelheim, GSK, Janssen Pharmaceutica NV, Merck KgaA, Novartis, and Institut de Recherches Servier * 2 academic universities: KU Leuven, Budapesti Muszaki es Gazdasagtudomanyi Egyetem * 4 subject matter experts: Owkin, Substra Foundation, Kubermatic, Iktos * 1 large AI computing company: NVIDIA #### About the Innovative Medicines Initiative The Innovative Medicines Initiative (IMI) is a partnership between the European Union and the European pharmaceutical industry, represented by the European Federation of Pharmaceutical Industries and Associations (EFPIA). It is working to improve health by speeding up the development of, and patient access to, the next generation of medicines, particularly in areas where there is an unmet medical or social need. More info on IMI: [www.imi.europa.eu](http://www.imi.europa.eu) #### Contact MELLODDY Communication: Kim ROTONDO – Janssen ([KRotondo@its.jnj.com](mailto:KRotondo@its.jnj.com)) ; Michèle BENTATA - OWKIN ([michele.bentata@owkin.com](mailto:michele.bentata@owkin.com)) #### Acknowledgement This project has received funding from the Innovative Medicines Initiative 2 Joint Undertaking under grant agreement No 831472. This Joint Undertaking receives support from the European Union’s Horizon 2020 research and innovation programme and EFPIA Companies. #### Disclaimer This communication reflects the views of the authors and neither IMI nor the European Union, EFPIA or any Associated Partners are liable for any use that may be made of the information contained herein. --- ## Automated Kubernetes Lifecycle Management With KubeOne - **URL:** https://www.kubermatic.com/blog/kubeone-simplified-lifecycle-management-for-ha-kubernetes-clusters/ - **Date:** 2026-05-07 - **Description:** KubeOne takes care of installing, configuring, upgrading and maintaining HA Kubernetes clusters and works out-of-the-box on any cloud provider. - **Categories:** Products, Community - **Tags:** KubeOne, Open Source Projects, Kubernetes - **Authors:** Marko Mudrinić Today, we are excited to announce a new open source Kubernetes cluster lifecycle management tool: [KubeOne](https://github.com/kubermatic/kubeone)! KubeOne takes care of installing, configuring, upgrading and maintaining Highly-Available (HA) Kubernetes clusters. It works out-of-the-box on any cloud provider, as well as in on-prem and bare-metal environments. With Kubernetes gaining more and more popularity each day, we believe that creating and maintaining HA Kubernetes clusters should be easy. Operators should focus on running the workload, not a bunch of commands to get clusters up and running. In search for a feature-complete solution that supports HA clusters, follows the Kubernetes best-practices, and comes with a simple and declarative API based on the Kubernetes Cluster-API, we could not find an exisiting project that fulfilled our needs. Therefore, we decided to build our own solution. #### Cluster Lifecycle Management KubeOne comes with a rich, easy to use, declarative Kubernetes-style API that allows you to configure your desired cluster in just a few lines. The configuration manifest defines on what instances Kubernetes will be installed, what Kubernetes version will be used, and what features will be enabled on the newly provisioned cluster. With the manifest in place, by using a single command, you can provision the cluster, upgrade it to the newer version, or destroy it. During the provisioning time, the user can enable and configure various features that improve the security and usability of the cluster. Supported features include [PodSecurityPolicy](https://kubernetes.io/docs/concepts/policy/pod-security-policy/), [DynamicAuditLog](https://kubernetes.io/docs/tasks/debug-application-cluster/audit/), [metrics-server](https://github.com/kubernetes-incubator/metrics-server) and [OpenID Connect authentication](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#openid-connect-tokens). Moreover, selected providers benefit from advanced features such as managing worker nodes with KubeOne and [Kubermatic Kubernetes Platform machine-controller](https://github.com/kubermatic/machine-controller) and deploying provider specific ones like [external cloud controller managers (CCM)](https://kubernetes.io/docs/tasks/administer-cluster/running-cloud-controller/). [Kubermatic Kubernetes Platform machine-controller](https://github.com/kubermatic/machine-controller) is a [Cluster-API](https://github.com/kubernetes-sigs/cluster-api) implementation that ensures you can manage all your worker nodes using a declarative Kubernetes-style API. That allows you to manage full lifecycle of worker nodes, including creating infrastructure, provisioning and upgrading Kubernetes, and destroying nodes using just `kubectl`. All worker nodes are backed by the MachineDeployment objects. MachineDeployments work just like Deployments, but instead of managing containers they manage machines. You can scale MachineDeployment objects using `kubectl` and the `scale` command. For example, the following command will set number of worker nodes to 5: ```bash kubectl scale machinedeployment/fra1-1-deployment -n kube-system --replicas=5 ``` <br> #### Terraform Integration KubeOne requires operators to provide the running instances for control plane nodes, instead of KubeOne provisioning them. This ensures users can continue using their favorite tools to create the infrastructure tailor-made to their needs on any provider, while enjoying all features of KubeOne. To ensure a seamless flow of information on the infrastructure and control plane nodes, and prevent potential errors and mistakes, KubeOne can read the needed information directly from the [Terraform](https://www.terraform.io/) output. We provide you with the [example Terraform scripts](https://github.com/kubermatic/kubeone/tree/master/examples/terraform) which can be used to create the needed infrastructure for a cluster. The example Terraform scripts are available for all [supported providers](#supported-providers-and-environments). #### `kubeadm` Under the Hood KubeOne uses the well-known and production-grade tool [`kubeadm`](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/). `kubeadm` allows you to follow the best practices for provisioning Kubernetes clusters, while providing a rich set of features that we make available in an easy to use manner. #### Supported Providers and Environments Despite being able to use KubeOne on any provider, in order to benefit from all features of KubeOne, the provider needs to be supported by KubeOne and [Kubermatic Kubernetes Platform machine-controller](https://github.com/kubermatic/machine-controller). Currently, KubeOne supports AWS, GCP, DigitalOcean, Packet, Hetzner and OpenStack. Support for VMware vSphere is planned for one of the upcoming releases. If you'd like to see support for other providers let us know via [GitHub](https://github.com/kubermatic/kubeone) or check [the guidelines for adding support for a new provider](https://github.com/kubermatic/kubeone/blob/master/docs/adding_provider_support.md). #### Getting Started with KubeOne Everything you need to do to get started with KubeOne is to grab the latest release from [GitHub Releases](https://github.com/kubermatic/kubeone/releases). The detailed installation instructions can be found in [the installing section of the README file](https://github.com/kubermatic/kubeone#installing-kubeone). In order to use the example Terraform scripts, you need to have Terraform installed, which can be done by following [the official installing instructions](https://learn.hashicorp.com/terraform/getting-started/install.html). [In the KubeOne documentation](https://github.com/kubermatic/kubeone/tree/master/docs) you can find a "Getting started" walkthrough for each supported provider. Alternatively, check out the recording showing KubeOne in action! <br> <a href="https://asciinema.org/a/244104" target="_blank"> <img src="https://asciinema.org/a/244104.svg" alt=Kubermatic class=Getting-started-with-KubeOne-walkthrough width="100%"></a> <br> #### Looking to the Future If you want to keep in the loop about what is happening, keep an eye at the [KubeOne GitHub repository](https://github.com/kubermatic/kubeone) and join the [\#kubeone](https://kubermatic.slack.com/messages/CHFK2HM5K) channel on [Kubermatic Kubernetes Platform Slack](https://app.slack.com/client/T0PGCH7CH/C0PGCH99P). We're planning many awesome features and we hope you'll like them! Also, we'll hold two Live Sessions at KubeCon + CloudNativeCon Europe in Barcelona: on Wednesday at 3:30 pm and on Thursday at 10:45 am! Just pass by our booth (SE56) to learn more about KubeOne and Kubermatic. If you are not able to join us at KubeCon, no worries. We'll be giving a [Kubernetes / Cloud Native Online Meetup](https://www.meetup.com/de-DE/Kubernetes-Cloud-Native-Online-Meetup/) dedicated to KubeOne on June 6th at 6 pm CEST. --- ## Working With My Colleagues Miles Away - **URL:** https://www.kubermatic.com/blog/working-with-my-colleagues/ - **Date:** 2026-05-07 - **Description:** Check out this blog post to learn what it is like to work for a Remote First company. - **Categories:** Company - **Tags:** Announcements - **Authors:** Frank Müller _Companies today are still sceptical about working as a distributed company. Individual days in home office may be okay, but having almost all colleagues sitting in their homes or coworking spaces across the world seems to be dubious. How will it influence the productivity of my team? Or what do I have to do to make them work together? How can I even make sure that they become a team? Take a look at how we've done it at Kubermatic._ Let's ask ourselves, what's the spirit and the power of great open-source projects? What drives them? Typically, it's a great idea and motivated people believing in this idea. However, usually there is one big hurdle: Those people aren't located in one place. Fortunately, the internet provides us with possibilities for those people to work together and act as a virtual team. These possibilities are: - Communication tools like mail, chat, and video conferences - Web platforms to manage open tasks and support planning - Distributed repositories for code management - Processes for changes together with tools for code reviews - Cloud-based platforms for continuous integration. - And last, but not least, real life get togethers at local meetings or conferences. All organised via the web. So, as a classic on-site company eager to establish a new work environment, you've got to ask yourself: Why not do it the same way? Why not solve the difficulties of getting committed and qualified people the same way the open source communities are doing it? It is for sure difficult to change established processes and tools. And it also may be difficult to live with the new kind of trust in their employees, working at home or their favourite place. But it is also very much doable. We at Kubermatic started out a distributed company. While sharing a few desks in our office in Hamburg three years ago, today you can find us also in Babensham, Belgrade, Berlin, Bosau, Chisinau, Gdansk, Gurajat, Lodz, Magdeburg, Mumbai, Munich, Oldenburg, San Francisco, Swinoujscie, Vienna, and Zurich. 35 people in 4 time zones with 10 different nationalities. This alone creates a real cool spirit and work environment. Sure, there are challenges working this way. Simple ways of communication, equivalent to walking around the corner in an office, have to be established. Transparency has to be created in a documented way, so that everyone can easily get an overview of the status of projects. The sharing of documents and source files has to be simple, while at the same time keeping an eye on the different internal as well as external access rights. And also typical office work like travel organisation, trip costs, or vacations needs to be managed. Like in the open source community, we have many service providers that help us solve these challenges. Our communication is mostly done via Slack, with different channels for different topics. Some external tools are integrated and send automated notifications into Slack, for example to inform the team about successful or failed builts or new Twitter mentions. Also important is Google Meet: to have regular as well as individual video meetings. Discussions, standups, retrospectives, and team meetings simply can be done better this way. And seeing each other's faces on a daily basis is nice – we are humans after all:) For planning and task management there are also tools, from a simple Google Calendar via ZenHub for project management based on the ideas of Kanban and issues on GitHub. The latter two are integrated, which helps you to keep an overview. GitHub also is our platform for source code management in different repositories and applying changes in form of pull requests. This allows to review the changes first and discuss possible improvements. Additionally, the PRs interact with the CI. So changes have to take some hurdles before they are applied. These tools are nothing special, but they simplify the asynchronous and distributed work. And like these code centric tools there are other web based helpers for travel, travel expenses, vacation, information exchange…. But tools are not everything. Working together as a functioning unit means and needs more. It is the culture we share, it is English as a common language, the different nationalities that come together, and it's the climate during video meetings. We are relaxed, share a common sense of humour, and have fun, even in the larger team meetings. Another good example is the weekly remote team lunch with colleagues eating in front of the monitor and talking about work, hobbies, life – you name it. The on-site counterpart to this event is the weekly team lunch for the people in Hamburg. Here one or more colleagues cook for the whole team. These social events help to bring the individual teams together. But we also have events that bring the whole team, remote and on-site, together. We have hackathons and team events on a regular basis with a few days of face-to-face interaction. Other events are our conferences [ContainerDays](https://www.containerdays.io/) and [GoDays](https://www.godays.io/) or the conferences that Kubermatic participates in. <br> <img src="/images/blog/2019-04-24/image1.jpg" alt="Team" width="100%"/> --- ## We Are Happy to Support LF Networking - **URL:** https://www.kubermatic.com/blog/we-are-happy-to-support-lf-networking/ - **Date:** 2026-07-02 - **Description:** Kubermatic is now a Silver Member of LF Networking to support its mission to harmonize open source networking across platforms, networks, and communities. - **Categories:** Company - **Tags:** Announcements - **Authors:** Kristin Wittig The Open Networking Summit seems like the right occasion to announce that Kubermatic is becoming a Silver Member of [LF Networking](https://www.lfnetworking.org/). We strongly support its mission to harmonize open source networking across platforms, networks, and communities. As an early member of the [Cloud Native Computing Foundation](https://www.cncf.io/), we seek to contribute to innovations in cloud native networking and connecting the communities. With our practical experience, we are committed to bringing the cloud native perspective into the projects of the Linux foundation and finding solutions to real-world use-cases. In a first step to advance the state-of-the-art in cloud native networking, we actively engage in the organisation of a Networking pre-conference Mini Summit prior to [KubeCon Barcelona](https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2019/) on May 20. Moreover, we plan to strengthen the exchange and collaboration of the cloud native and the networking community via our [Kubernetes/Cloud Native Meetups](/company/about-kubermatic/) across Europe. We are excited to join the LF Networking and its projects for the exciting journey that lies ahead. <br> --- ## Kubernetes Day India 2019: How to Contribute to Kubernetes - **URL:** https://www.kubermatic.com/resources/kubernetes-day-india-2019-talk-nikhita-raghunath-how-to-contribute-to-kubernetes/ - **Date:** 2026-03-17 - **Description:** Do you want to contribute to Kubernetes? Not sure how or where to begin? Learn how to get started. # Kubernetes Day India 2019: How to Contribute to Kubernetes ![download Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/static/predicts-2026-container-management-becomes-ai-enabler-popup_hu_d9e9fd9e91e19010.png) [Gartner® Predicts 2026: Container Management Becomes an AI Enabler](/predicts-2026-container-management-becomes-ai-enabler/) Play Video Video ## How to Contribute to Kubernetes Do you want to contribute to Kubernetes? Not sure how or where to begin? It can be overwhelming! But fear not - you can join the thousands of successful contributors too! In this talk, Nikhita Raghunath from Kubermatic will explore the different parts of Kubernetes and how they work, see how the various components are related, discuss the skills you need to get started and learn the best ways to get your first Pull Request accepted. ## Leading Companies Choose Kubermatic ![Siemens](/static/siemens-ifl.png) ![T-Systems](/static/t-systems.svg) ![Hilti](/static/hilti.svg) ![Allianz](/static/allianz.svg) ![1&1](/static/1&1.svg) ![Bosch](/static/bosch.svg) ![Lufthansa](/static/lufthansa.svg) ![Vonage](/static/vonage.svg) ![CNCF](/static/cncf.svg) ![Interhyp](/static/interhyp.svg) ![Cube](/static/cube.svg) ![EXL](/static/exl.svg) ![Wobcom](/static/wobcom.svg) ![FHE3](/static/fhe3.jpg) ![DialogData](/static/dialogdata-color.svg) ![Switch](/static/switch.svg) ![inventx](/static/inventx.png) ![Datagroup](/static/datagroup.svg) ![Krone](/static/krone.svg) ![Runtastic](/static/runtastic.png) ![Charite](/static/charite.svg) ![Justus-Liebig-Universität Gießen](/static/jlu-giessen.svg) ![Heidelberg University](/static/university-heidelberg.svg) ![Swisscom](/static/Swisscom.svg) ## Ready to get started? [Contact Us](/contact-us/) --- ## Kubernetes in CI Pipeline: Integration & E2E Tests - **URL:** https://www.kubermatic.com/blog/running-kubernetes-in-the-ci-pipeline/ - **Date:** 2026-05-07 - **Description:** Learn how to run Kubernetes in the CI pipeline with kind. - **Categories:** Community - **Tags:** Kubernetes, Open Source Projects - **Authors:** Marko Mudrinić Ensuring your Kubernetes component, such as a controller or an operator, works correctly is an important step before merging a pull request or deploying it to the production. You want to be sure that incoming changes will not introduce any regression or negatively effect any part of the system. This is usually done by running integration and end-to-end tests in the CI/CD pipeline. They test the component on all incoming changes, automatically and in a clean environment, and thereby prevent potential errors and flakes. However, integration and E2E tests assume there is a working Kubernetes cluster. While there are many tools for running Kubernetes (such as `kubeadm` or tools based-on `kubeadm`) many developers experience a lot of problems trying to get Kubernetes running in the CI environment. The CI environments are usually as minimal as possible, while Kubernetes has many dependencies. Installing all the needed dependencies can take a lot of time and sometimes it's not even possible. We want to run Kubernetes using what we already have installed and configured in the CI pipeline and usually that's Docker. In this blog post you're going to see how you can do this by using [_kind_](https://github.com/kubernetes-sigs/kind) and how is it going to change your experience. This blog post is a follow-up and update of the talk I held during KubeCon 2018 Seattle: [Spawning Kubernetes in CI for Integration Tests](https://sched.co/GrUv). <br> <a href="http://www.youtube.com/watch?feature=player_embedded&v=ZiJn7olAS1M" target="_blank"><img src="/images/blog/2019-03-12/image1.jpg" alt=Kubermatic class=KubeCon-North-America2018_Spawning-Kubernetes-in-CI-for-Integration-Tests_Lightning-Talk width="100%"></a> <br> #### [*kind*](#kind) (Kubernetes in Docker) <a name="kind"></a>[_kind_](https://github.com/kubernetes-sigs/kind) is a tool for running local Kubernetes clusters using Docker containers as nodes. It supports Kubernetes 1.11+, multi-node, and high-available clusters. _kind_ is suitable for running on local machines for development purposes, with support for Linux, macOS, and Windows. It has been developed with the objective to ensure you can easily get a Kubernetes clusters, but also with the intention to be used in the CI pipelines for integration tests. _kind_ clusters are customizable, either by using CLI flags, by specifying a _kind_ configuration file, or by using a custom node image. We'll see more about those concepts throughout the blog post. Before we proceed to running clusters using *kind*, let's have a look at some core concepts and the main differences between _kind_ and other solutions. #### How Does _kind_ Work? There are many different tools for running Kubernetes clusters, like for instance Minikube and `kubeadm` to mention the most popular ones. This raises the question what the difference between them is and when you should choose _kind_. While Minikube is doing a great job at bringing local Kubernetes clusters, bringing Kubernetes 1.11+ clusters requires `systemd` if used with the `--vm-driver=none` option, which is often unavailable in the CI environments, or a virtual machine which requires a hypervisor and takes plenty of resources. Similar, `kubeadm` also needs `systemd` to fully provision the cluster and may be hard to configure depending on the environment. _kind_ is pursuing a different approach: it uses Docker containers as cluster nodes. Before bootstrapping a cluster, _kind_ creates a container using the _**node image**_, which contains everything needed for `kubeadm` to bootstrap a cluster: `systemd`, Docker, `kubeadm` itself, and all needed dependencies. Once the node container is created, _kind_ invokes `kubeadm` which sets up Kubernetes inside the newly created container. This way, we can run Kubernetes using just Docker, which is very suitable for CI and testing environments. There are no complex dependencies and you can quickly create and destroy clusters. In this blog post we'll not go in-depth into _kind_ design, but if you'd like to learn more, make sure to check out [_kind_ Design Principles](https://kind.sigs.k8s.io/docs/design/principles/). Now that we have an idea how _kind_ works, let's see how to use _kind_ and how to run it in the CI pipeline. #### Creating Kubernetes Clusters Using _kind_ _kind_ comes with a simple and straightforward CLI. You can create a cluster with a single command, which takes care of everything including setting up all needed Docker containers, provisioning the cluster and creating the Kubeconfig file. Before we start, we need to download and install _kind_. There are two ways: using `go get` or downloading a binary from [GitHub Releases](https://github.com/kubernetes-sigs/kind/releases). Using the Go toolchain may be the easiest way and you always get all the latest changes, but running from the master branch always introduces risks as it can break at any time. The _kind_ team is doing a great job at ensuring the master branch never breaks but if stability is very important to you, you should consider using releases. If using the Go toolchain, you can download _kind_ with: ~~~bash go get -u sigs.k8s.io/kind ~~~ Alternatively, if you prefer using stable releases, you can obtain _kind_ using cURL and then move it to the `PATH`: ```bash curl -Lo kind https://github.com/kubernetes-sigs/kind/releases/download/0.1.0/kind-linux-amd64 && chmod +x kind && sudo mv kind /usr/local/bin/ ``` After that, you should be able to create a cluster using the following command: ```bash kind create cluster ``` This command creates a single-node Kubernetes cluster. The cluster version depends on the node image that your _kind_ version uses, but you can always specify the node image to be used with the `--image` flag. Node images can be found in the [`kindest/node`](https://hub.docker.com/r/kindest/node) Docker Hub repository. [Tags](https://hub.docker.com/r/kindest/node/tags) are named based on the Kubernetes version, so for Kubernetes 1.13.3, you would use the `kindest/node:v1.13.3` image. ```bash kind create cluster --image "kindest/node:v1.13.3" ``` **Note:** If you're running _kind_ version 0.1.0, it's highly recommend to use the `kindest/node:v1.13.3` image instead of default (`kindest/node:v1.13.2`) due to the recently discovered [CVE-2019-5736](https://access.redhat.com/security/vulnerabilities/runcescape)! Once the cluster is provisioned, you can use the `kind get kubeconfig-path` command to get a path to the Kubeconfig file. If you're using `kubectl` to interact with the cluster, you can set the `KUBECONFIG` environment variable, so you don't always have to specify the path when interacting with `kubectl`: ```bash export KUBECONFIG=$(kind get kubeconfig-path) ``` **Note:** If you're running `kubectl` using Makefiles, this approach might not work. Instead, you should inline the environment variable or use the `--kubeconfig` flag. ```bash KUBECONFIG=$(kind get kubeconfig-path) kubectl get nodes kubectl --kubeconfig=$(kind get kubeconfig-path) get nodes ``` In case you need to delete a cluster, you can use: ```bash kind delete cluster ``` When you use commands such as `create`, `get` and `delete`, they use `kind` as the default cluster name. You can configure the cluster name with the `--name` flag. This also allows you to create and run multiple clusters at the same time. #### Advanced Configuration The _kind_ CLI can be only used for basic configuration, such as setting the cluster name or a node image to be used. Configuring multi-node or high-available clusters and changing advanced options are done via the _kind_ configuration file. For example, if you want to create a cluster with a control plane node and three worker nodes, you'd use a configuration file like this: <pre class="code-block" data-lang="yaml"> <span class="key">apiVersion:</span> <span class="value">kind.sigs.k8s.io/v1alpha2</span> <span class="key">kind:</span> <span class="value">Config</span> <span class="key">nodes:</span> <span class="key">- role:</span> <span class="value">control-plane</span> <span class="key">- role:</span> <span class="value">worker</span> <span class="key">replicas:</span> <span class="value">3</span> </pre> The configuration is provided to the `create cluster` command using the `--config` flag. ```bash kind create cluster --config config.yaml ``` You can check out an [example configuration file](https://raw.githubusercontent.com/kubernetes-sigs/kind/master/site/content/docs/user/kind-example-config.yaml) for more details on how you can use configuration files to configure your clusters. **Note:** The _kind_ configuration file is in the alpha status at time of writing this post. Breaking changes are expected in the upcoming period, so make sure to check [_kind_ documentation](https://kind.sigs.k8s.io/docs) for an up-to-date reference. Finally, we can use this knowledge to run a cluster in the CI environment. #### Using _kind_ in Travis-CI For this blog post, we'll see how to use _kind_ in Travis-CI as it's the most popular CI pipeline among the open source projects. These steps should work in any other CI pipeline as long there is properly configured Docker available. We just need to grab _kind_ binary and use the `kind create cluster` command to start the cluster. Optionally, you may want to download `kubectl` as well. We're going to do that in the `before_script` phase, which is used to prepare the environment and we'll run actual tests in the `script` phase. <br> <pre class="code-block" data-lang="yaml"> <span class="key">language:</span> <span class="value">go</span> <span class="key">go:</span> <span class="value">- '1.12.x'</span> <span class="key">services:</span> <span class="value">- docker</span> <span class="key">jobs:</span> <span class="key">include:</span> <span class="key">- stage:</span> <span class="value">Integration Tests</span> <span class="key">before_script:</span> <span class="comment"># Download and install kubectl (optional)</span> <span class="value">- curl -Lo kubectl</span> <span class="key">https://storage.googleapis.com/kubernetes-release/release/v1.12.0/bin/linux/amd64/kubectl</span> <span class="value">&& chmod +x kubectl && sudo mv kubectl /usr/local/bin/</span> <span class="comment"># Download and install kind using Go toolchain</span> <span class="value">- go get sigs.k8s.io/kind</span> <span class="comment"># Download and install kind using cURL</span> <span class="comment"># - curl -Lo kind https://github.com/kubernetes-sigs/kind/releases/download/0.0.1/kind-linux-amd64 && chmod +x kind && sudo mv kind /usr/local/bin/</span> <span class="comment"># Create a new Kubernetes cluster using kind</span> <span class="value">- kind create cluster</span> <span class="comment"># Set KUBECONFIG environment variable</span> <span class="value">- export KUBECONFIG="$(kind get kubeconfig-path)"</span> <span class="key">script:</span> <span class="value">make test-integration</span> </pre> <br> If you're using a _kind_ configuration file, I'd recommend using stable releases rather than obtaining _kind_ using `go get`. This ensures potential backwards incompatible changes are not going to break your tests and the CI pipeline. For more details, you can check out [`travis-kind` example repository](https://github.com/xmudrii/travis-kind) that contains `.travis.yml` along with the additional resources. #### Loading Docker Images Into Your Cluster Often when running integration and end-to-end tests, you want to build a Docker image for your component locally, in the pipeline, and use it for tests. Pushing images for tests to a remote registry is something we want to avoid. As _kind_ clusters are using Docker in the node container, we need to push image from Docker running on the local machine to Docker running in the node container. Docker images can be loaded into _kind_ clusters using the `kind load docker-image` command. Usually we'd do something such as: ```bash docker build -t my-image:tag . kind load docker-image my-image:tag kubectl create -f manifest-using-my-image.yaml ``` **Note:** the `kind load` command is not available in the `v0.1.0` release. **Note:** You should avoid using the `latest` tag when building images for _kind_ clusters. By default, Kubelet pulls image from a remote registry if the `latest` tag is used unless [`imagePullPolicy`](https://kubernetes.io/docs/concepts/containers/images/#updating-images) isn't set to `Never` or `IfNotPresent`. #### _kind_ Project Status _kind_ is a new project and currently in the alpha status. However, it's very stable and many projects are using it for their CI tests, including: * [Kubernetes](https://github.com/kubernetes/test-infra/pull/11445), * [Kubernetes Federation v2](https://github.com/kubernetes-sigs/federation-v2), * [jetstack/cert-manager](https://github.com/jetstack/cert-manager) If you want to get involved, make sure to check out [the project repository](https://sigs.k8s.io/kind) and [the project website](https://kind.sigs.k8s.io/). _kind_ has the [#kind](https://kubernetes.slack.com/messages/CEKK1KTN2) channel on Kubernetes Slack where you can get in touch with users and maintainers. #### Conclusion _kind_ is a fast and easy to use tool for creating local Kubernetes clusters. It has been developed with the objective to be used in CI environments and so far works very well for many projects. This blog post should give you a quick introduction on how to get started. However, _kind_ has many more features, so take a look at the [_kind_ website](https://sigs.k8s.io/kind) for more details on design and advanced use cases. --- ## Cloud Native Best Practices #1: Cutting Costs - **URL:** https://www.kubermatic.com/blog/cloud-native-best-practices-1-containerization-cuts-costs/ - **Date:** 2026-05-07 - **Description:** This blog is the first of a seven-part series examining how cloud native can help businesses deliver on their promise of better, faster, cheaper. - **Categories:** Best Practices - **Tags:** Kubernetes - **Authors:** Bill Mulligan To <a href="https://www.forbes.com/sites/richkarlgaard/2017/08/08/how-michael-dell-reinvented-his-company/?linkId=40742788#208a6a9548a7">quote Michael Dell</a>, “the cloud isn’t a place, it’s a way of doing IT.” According to the Cloud Native Computing Foundation (CNCF), in the past 9 months, production cloud native deployments - across public clouds and private data centers - have <a href="https://www.cncf.io/blog/2018/08/29/cncf-survey-use-of-cloud-native-technologies-in-production-has-grown-over-200-percent/">increased by over 200%.</a> Cloud native provides numerous benefits, but with an <a href="https://landscape.cncf.io/">ever expanding landscape</a> of tools, projects, and providers it can be confusing to know where to start - let along where to go. While developers and operators can turn to the variety of resources, like StackOverflow or community Slack channels, to help them understand and implement these technologies, there are vastly fewer resources for building the business case for cloud native computing. Without an understanding of the business case, it can be difficult for IT departments to get buy-in across departments to transition towards much needed cloud native computing. Every business is premised on providing a product or service to their customers that is better, faster, cheaper, or, ideally, a combination of the three. This blog is the first of a seven-part series examining how cloud native can help businesses deliver on their promise of better, faster, cheaper. They will cover containerization, pets vs. cattle, open source, backup and disaster recovery, API driven programming, monitoring, and security. The goal of the series is to provide a roadmap to help teams build the business case for a cloud native approach. #### Learn more Containerization is actually the first step on the <a href="https://www.cncf.io/blog/2018/03/08/introducing-the-cloud-native-landscape-2-0-interactive-edition/">CNCF Cloud Native Trail Map.</a> There are multiple reasons to adopt containers including legitimate portability (better), improved developer experience, productivity, and velocity (faster), and reduced resource utilization (cheaper). From a pure P&L point of view, this last point is the most tangible. <br> <img src="/images/blog/2019-02-26/image1.png" alt="Containerization" width="100%"/> <br> <a href="https://www.docker.com/resources/what-container">A container is a standardized packaging of code</a> - and all of its dependencies - that allows applications to run quickly and reliably from one environment to another. It is a further abstraction of a virtual machine (VM) (check out our blog post “Cloud Native for Non-Coders” if you want to learn or refresh the difference between a container and VM). Instead of having to virtualize everything including the kernel and OS for every application, like when using VMs, multiple applications, each in a separate container, can share the same OS. This provides many benefits tangible business benefits including isolating dependencies to create a better product, increasing delopyment speed, and reducing computing expenses. Below is a deeper dive into how containerization cuts costs. #### Containerization Cuts Costs When designing our Kubermatic Kubernetes Platform Container Engine, we knew containerizing the management components of user Kubernetes clusters would reduce the overall cost of management for our customers. Using containers rather than virtual machines (VMs), like kubespray, kops, and Rancher, allows us to **reduce our customer’s infrastructure costs 5x.** Below is an example cost comparison between Kubernetes cluster managed with VMs and clusters managed with containers. All pricing information is pulled from the AWS calculator. #### Example calculations: To run in production stable, high availability mode, each user Kubernetes cluster requires 3 t3.medium VMs with at least 2 vCPU & 4GB RAM. Pulling pricing from the the <a href="https://aws.amazon.com/de/ec2/pricing/">AWS calculator</a> Frankfurt region, each user cluster costs $105.42 per month. Thus, to run 1,000 clusters in production for a month costs $105,420 in just management overhead. Kubermatic Kubernetes Platform follows cloud native best practices and instead uses containers to manage user Kubernetes clusters. Each Kubernetes cluster only requires 2 GB of RAM to host the containers of the control components. Thus, Kubermatic Kubernetes Platform can run 1,000 clusters on only 33 m5.4xlarge VMs each with 16 vCPU & 64GB - at a total cost of only $ 22,223.52 per month. Using a container rather than a VM based management model helps us reduce the cost of cluster management for our customers almost 5x. <br> VMs:\ 1 User Clusters&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;= 3 x VM\ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;= 3 x t3.medium\ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;= 3 x $35.14\ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;= $105.42 1,000 User Clusters&nbsp;&nbsp;= 3000 VMs for Masters = **$105,420 per month** <br> Containers:\ 1 User Cluster &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;= 2 GB RAM\ 30 User Clusters &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;= 1 x m5.4xlarge\ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;= 1 x $ 673.44\ 1,000 User Cluster&nbsp;&nbsp;&nbsp;&nbsp;= 33 VMs for Masters = **$22,223.52 per month** <br> Containerization is only the first step on the cloud native journey and is only part of the cloud native business case. Check out part two: Pets vs Cattle to understand how to design a better production system. --- ## GoDays Berlin Recap - **URL:** https://www.kubermatic.com/blog/godays-berlin-recap/ - **Date:** 2026-05-07 - **Description:** Over the course of two days over 400 Go enthusiasts had the chance to interact with each other through a variety of workshops and talks. - **Categories:** Company, Community - **Tags:** Events, Announcements - **Authors:** Bill Mulligan Go is quickly becoming one of the most popular programming languages. In addition, many of the fastest growing open source projects, like Kubernetes and Prometheus, are also written in Go. At Kubermatic, the core of our product Kubermatic Kubernetes Platform is written in Go and it is the fan favorite language of our developers. Although there are numerous Go Meetups around the DACH region, we felt that there was no central platform for the Go community to gather around. That is why we reached out to <a href="https://www.meetup.com/Women-Who-Go-Berlin/">Women Who Go</a> and the <a href="https://www.meetup.com/golang-users-berlin/">GDG Berlin Golang Meetup</a> to support us organizing the first Go conference in the DACH region. And what can we say? By all counts, the first edition of <a href="https://www.godays.io/">GoDays Berlin</a> was a resounding success! Over the course of two days over 400 Go enthusiasts had the chance to interact with each other through a variety of workshops, talks, and casual “hallway track” conversation. Although GoDays was hosted in Berlin, that didn’t stop people traveling from much further afield to attend. Over 30 countries were represented including people from Japan and the USA! All of these marks really speak to the growing importance of Go to the future of IT and the open source ecosystem. Day one was filled with packed workshops. We were especially excited to have Michael Hausenblas and Dr. Stefan Schimanski from Red Hat give a workshop that allowed attendees to dive in and get their hand dirty with Go and Kubernetes. We hope we have more space for more workshops next year. The day ended at a pre-conference <a href="https://www.meetup.com/golang-users-berlin/">Golang MeetUp</a> hosted by <a href="https://www.syseleven.de/">SysEleven</a>. It was entertaining to see how Daisy Tsang used Go and Prometheus to improve her bread baking. Day two was the actual conference and began before half of Berlin had even woken up for work. The conference was hosted in the penthouse of the hipster Factory Berlin coworking space. This provided the perfect location to see the sunlight streaming in rather than the typical grey Berlin winter day. Our favorite part of the venue was the Cinema stage that had comfortable couches rather than typical conference chairs. Natalie Pistunovich kicked off the day talking about the importance of beginners since half of the Go community has joined in only the last year! We were proud to have both Guus van Weelden and Marko Mudrinić on stage to represent Kubermatic. Though after his talk in front of 2,000 people at KubeCon, the GoDays Berlin stage was easy for Marko. The day finished with a keynote from Ronna Steinberg, Women Who Go Berlin Chapter Lead, speaking about diversity in tech - definitely words worth spreading. Beyond the conference, GoDays Berlin was also a chance for our whole team to gather and get to know one another better. With more than 30 people spread from India to San Francisco, we don’t often get a chance to interact outside a video conference. Berlin provided the perfect location for team bonding across a variety of different experiences. Staying next to Berlin’s (in)famous Görlitzer Park in Kreuzkölln gave us a chance to experience the artistic side of Berlin. We stayed out late in a smoke filled Kneipe diving into deeper conversations with Bill’s deck of cards and revived the next morning in a hipster organic coffee bar. A couple of colleagues from Poland even got the chance to experience how spread out Berlin really is when they decided to go sightseeing by foot to the East Side Gallery, Alexanderplatz, and the Brandenburg Tor. As you can tell from our pictures, it was a great chance to come together as a company at a top-notch event :) #### Where to learn more Pictures on the <a href="https://www.godays.io/pictures">GoDays Website</a> All speaker decks on <a href="https://speakerdeck.com/godays">SpeakerDeck</a> <br> <img src="/images/blog/2019-02-07/image2.jpg" alt="GoDays 2" width="100%"/> <br> <img src="/images/blog/2019-02-07/image3.jpg" alt="GoDays 3" width="100%"/> <br> <img src="/images/blog/2019-02-07/image4.jpg" alt="GoDays 4" width="100%"/> <br> <img src="/images/blog/2019-02-07/image5.jpg" alt="GoDays 5" width="100%"/> <br> <img src="/images/blog/2019-02-07/image7.jpg" alt="GoDays 7" width="100%"/> --- ## KubeCon Seattle Recap - **URL:** https://www.kubermatic.com/blog/kubecon-seattle-recap/ - **Date:** 2026-05-07 - **Description:** With 8,500 conference attendees, KubeCon Seattle has made it clear that the tidal wave of Kubernetes has truly hit the shore of enterprise IT. - **Categories:** Company - **Tags:** Events, Announcements - **Authors:** Bill Mulligan Since we were last in Seattle for KubeCon two years ago, the rainy weather hasn’t changed, but the Kubernetes community has undergone a drastic change. With 8,500 conference attendees and a waiting list of over 1,400 people, the tidal wave of Kubernetes has truly hit the shore of enterprise IT. <a href="https://www.forbes.com/sites/jasonbloomberg/2018/12/15/top-nine-vendor-highlights-from-kubecon/">To quote Forbes</a> after the conference, "Kubernetes is here to stay, and will provide the overarching framework for how enterprises deploy their software infrastructure for years to come." We had a team of eight to cover the conference, but even that wasn’t nearly enough to catch everything. The whole Kubermatic team would like to thank all of the wonderful people contributing to the Kubernetes community, especially Nikhita for being honored with the <a href="https://www.cncf.io/blog/2018/12/14/closing-out-2018-with-a-top-notch-cloud-native-community-event/">"Chop Wood, Carry Water"</a> award for the work she is doing to help maintain the community. With only a 13% acceptance rate for talks, we are proud that both Marko and Sebastian were among the many wonderful speakers at KubeCon. Marko (in his first talk ever in front of 1,300 people) talked about using KinD to spawn local Kubernetes clusters for CI test while Sebastian talked about using KubeVirt to deploy and manage VMs with Kubernetes (talks below). Every time slot had multiple talks we wanted to attend and, as always, Kelsey Hightower's keynote was a highlight explaining how to become a 10x developer and work multicloud while still creating a great developer experience. The breadth and variety of sponsors, from Apple to Yahoo, really speaks to the community that the CNCF has created around the whole cloud native ecosystem. This also lead to a packed conference floor. From when the conference opened at 7:30 AM <b>(!!!)</b> on Tuesday morning until it closed on Thursday, our booth received a torrent of people interested to learn how we run Kubernetes in Kubernetes. The team also had a little time to escape the container craziness including team building making a jet-lagged pancake breakfast, hiking through the natural beauty of the Pacific Northwest, and a visit to the Pike Place Market. We are already excited for KubeCon Barcelona and have many great ideas in store. Seeking a consistent experience to deploy and manage any workload? Check out the KubeVirt talk below. #### What you’ll learn - How to launch machines on any infrastructure with MachineController - How KubeVirt works to declaratively create VMs - How to migrate VMs across Kubernetes clusters <br> {{< youtube id="VmZ_YaWZmBQ" feature="youtu.be" >}} <br> #### Where to learn more <a href="https://kubevirt.io/">KubeVirt</a> Seeking an easy way to spin up a local Kubernetes cluster? Check out the KinD talk below. #### What you’ll learn - How to run Kubernetes in Docker - How to run simple local integration tests <br> {{< youtube id="ZiJn7olAS1M" list="PLj6h78yzYM2PZf9eA7bhWnIh_mK1vyOfU" >}} <br> #### Where to learn more <a href="https://github.com/kubernetes-sigs/kind">KinD</a> <a href="https://blog.alexellis.io/be-kind-to-yourself/">Local Kubernetes deployment comparison</a> --- ## Announcing OpenShift on Kubermatic Kubernetes Platform - **URL:** https://www.kubermatic.com/blog/red-hat-openshift/ - **Date:** 2026-05-07 - **Description:** We are happy to announce the closed beta availability of Red Hat OpenShift for Kubermatic Kubernetes Platform. - **Categories:** Products - **Tags:** KKP, Events - **Authors:** Kristin Wittig Just in time for the KubeCon and CloudNativeCon in Seattle, we are happy to announce the closed beta availability of Red Hat OpenShift for Kubermatic Kubernetes Platform Container Engine. By bringing OpenShift on Kubermatic Kubernetes Platform, customers benefit from even more options: They can freely choose how and where to run their containerized workloads without cost and resource intensive builds. Kubermatic Kubernetes Platform provides native support for Bare Metal, VMware, and OpenStack environments for on-prem, as well as public cloud deployments, including Azure, AWS, and GCP. The rapid uptake of cloud computing and cloud native technologies is quickly transforming enterprise infrastructure: Pets that were once hard to raise have become cattle - large numbers of nameless, easy-to-care-for machines. Although we’re very excited about the potential of these technologies, the reality is that OpenShift clusters have become the new pets: Hard to raise, maintain, and replace. Our goal is to help businesses run their container-based infrastructure as cattle with instances that are easy to set up, manage, and dispose - regardless of location and scale. That’s why we integrated OpenShift into Kubermatic Kubernetes Platform: to provide businesses with a low-maintenance and reliable way to deploy and manage their OpenShift infrastructure. OpenShift on Kubermatic Kubernetes Platform Container Engine empowers businesses to: * Set up multiple OpenShift clusters and add nodes at the click of a button. * Run and operate clusters on any infrastructure on-premise, in the cloud or hybrid with one unified UI experience. * Benefit from powerful features including automated updates, automated scheduling, automated backups, configurations management, user management and logging and metrics. <br> __Preview__ <img src="/images/blog/2018-12-11/preview-img-1.png" alt="Preview Image 1" width="100%"/> <br> <img src="/images/blog/2018-12-11/preview-img-2.png" alt="Preview Image 2" width="100%"/> <br> __Learn more__ <br> * <a href="/pdf/blog/KubermaticUseCaseSysEleven.pdf">Read why SysEleven relies on Kubermatic Kubernetes Platform</a> * <a href="mailto:sales@kubermatic.com">Request access</a> --- ## Empowering SysEleven to Manage Their Own Infrastructure - **URL:** https://www.kubermatic.com/blog/empowering-syseleven-to-manage-their-own-infrastructure/ - **Date:** 2026-05-07 - **Description:** SysEleven turned to Kubermatic to help them fulfill their vision and create MetaKube, a white label of Kubermatic Kubernetes Platform. - **Categories:** Products - **Tags:** KKP, Kubernetes - **Authors:** Bill Mulligan SysEleven is one of central Europe’s premier hosting companies with eleven years of delivering high-quality services to over 450 customers. At SysEleven’s core is a team of dedicated experts who believe that the best managed-hosting experience comes from partnering with customers to find the right solution. In a continuous exchange with customers, SysEleven is determined to make the latest and greatest technology easily accessible at an affordable rate. SysEleven leverages OpenStack to provide their underlying infrastructure. As customers began turning towards cloud native technologies like Docker and Kubernetes, SysEleven sought out to create a new platform to meet the needs of their customers without sacrificing stability or security. Building their own Kubernetes engine would take too long to bring to market and had an unknown operational overhead. Thus, because the hosting market is extremely competitive, SysEleven sought a partner to help them bring a solution to market.They found that Tectonic, OpenShift, and Rancher did not meet their needs as a managed hosting provider. It would be impossible to manage individual clusters for every customer. They needed a product which would allow them to install one big management cluster within their environment and give customers a self-service portal to log in to. For SysEleven it was imperative that customers had the ability to install their own clusters, delete them, extend them, and contain all of the tools needed to manage Kubernetes. SysEleven ultimately turned to Kubermatic to help them fulfill their vision and create MetaKube, a white label of Kubermatic Kubernetes Platform. They chose Kubermatic Kubernetes Platform for four key reasons: First, the maintenance overhead was much lower. The Kubernetes in Kubernetes architecture allows them to manage all of their customer clusters while only having to actively maintain one seed cluster. Second, Kubermatic Kubernetes Platform provided a self-service portal for customers, empowering them to manage their own infrastructure. Third, Kubermatic Kubernetes Platform can integrate with other cloud providers allowing customers to access services of other providers while still keeping them within the SysEleven ecosystem. Finally, Kubermatic was a real partner on the journey, listening to feedback, making SysEleven a part of the product roadmap, and creating a solution that fit their needs. <br> <img src="/images/blog/2018-12-06/metaKube.jpg" alt="MetaKube Logo" width="100%"/> <br> Working with Kubermatic on MetaKube has made SysEleven engineers more efficient and begun to break down a service model that used to be very staff intensive. Kubermatic gave SysEleven the ability to quickly roll out a new product to meet their customer needs while keeping operational overhead low. SysEleven successfully launched MetaKube in August 2018 living up to their promise of always providing the latest and greatest technology to their customers. **Download the whole interview with Simon Pearce on SysEleven’s journey towards Kubernetes and MetaKube [here.](/pdf/blog/KubermaticUseCaseSysEleven.pdf)** #### Learn more: <a href="https://metakube.syseleven.de/" target="_blank"> Try MetaKube </a> <br> <a href="/demo/" target="_blank"> Test a free trial of Kubermatic Kubernetes Platform </a> --- ## Introduction to Kubernetes Cluster-API Project - **URL:** https://www.kubermatic.com/blog/introduction-to-kubernetes-cluster-api-project/ - **Date:** 2026-05-07 - **Description:** The Cluster API project brings declarative, Kubernetes-style API for managing clusters and machines. - **Categories:** Community - **Tags:** Kubernetes, Open Source Projects - **Authors:** Marko Mudrinić [Kubernetes Cluster-API](https://github.com/kubernetes-sigs/cluster-api) is an attempt to bring declarative, Kubernetes-style API for managing clusters and machines. It allows you to define all Cluster and Machines as Kubernetes objects (based on CustomResourceDefinitions) and then a cloud-specific Cluster-API provider will reconcile your request, i.e. make sure your requested state is what you have in cloud. With the help of `clusterctl`, Cluster-API can also create you a new Kubernetes cluster from zero. We are going to deep dive into Cluster-API, see how it got started, how it looks and works like now, but also how you can get involved in Cluster-API development. #### Short History of Cluster-API Provisioning and managing Kubernetes clusters have always been a challenging job. Installing all dependencies, configuring components such as Kubelet, Scheduler, etcd, generating certificates... is all very time-consuming. There are so many different setups and so many different cloud providers to support. To make this job easier, the Kubernetes community created two tools to simplify the cluster provisioning and maintenance process: [`kops`](https://github.com/kubernetes/kops) and [`kubeadm`](https://kubernetes.io/docs/setup/independent/install-kubeadm/). `kubeadm` is a cloud-agnostic tool that initializes and configures Kubernetes, as well as handles cluster upgrades, for both master and worker instances. However, `kubeadm` is not supposed to be used for anything beside setting up Kubernetes or to be used as an API. It is up to operator to set up provisioning logic that is going to create virtual machines and other relevant resources, as well as to set up machines. `kops` is a tool that set ups Kubernetes, but also handles provisioning—creating cloud resources, installing dependencies and configuring virtual machines, as well as comes with an API and can integrate with Terraform. However, `kops` initially only supported AWS, with support later extended for GCE and DigitalOcean (currently in alpha). While both tools are great and solve many problems, there are several important problems left to solved: * We want a declarative, Kubernetes-like API, so we can manage infrastructure in fashion we got used to, * The API should be compatible with tooling we already have, i.e. with `kubectl`, * We're not limited to cloud provider—everybody can easily implement API calls for the desired provider, * The tool installs and configures all required dependencies and then initialize the cluster, * The tool allows you to bring your own provisioning logic for setting up clusters, * The tool allows you to snapshot, scale, and upgrade cluster. An attempt to solve this problem and bring such tool was made by Kris Nova with [**kubicorn**](http://kubicorn.io/). While `kubicorn` may look similar to `kops`, there are several huge differences, such as: allowing users to easily bring support for any cloud provider, to use any bootstrap script to provision the cluster, to use `kubicorn` as a Go library, and many more. And `kubicorn` had a great success! The community really loved the tool as it was easy to get an Kubernetes cluuster just like you would like. What `kubicorn` was missing is a better integration with Kubernetes and the Kubernetes-like API. To manage your cluster you still had to use the `kubicorn` CLI or use it as a Go library. The introduction and adoption of CustomResourceDefinitions allowed us to build a tool and an API that would bring similar feature-set as `kubicorn` and `kops`, but also integrate with the Kubernetes API, allowing operators to manage their infrastructure using existing tools, such as `kubectl`. #### Cluster-API [The Kubernetes Cluster-API](https://github.com/kubernetes-sigs/cluster-api) is an official Kubernetes project, lead by experience gained while working on `kops` and `kubicorn`. Cluster-API is a declarative API built on top of Kubernetes, making it possible to provision and manage your cluster using the tool we know very well—`kubectl`. While the project has `API` in its name, it is not really just an API. Actually, we can look at it like at a framework. It provides API, but also comes with controller that reconciles your cluster—creates, updates and deletes resources in the cloud. Beside the controller, we have a CLI called `clusterctl` which is used to create a new cluster from zero. While Cluster-API is appreciated and liked by community, it still has various pros and cons. Pros: * Declarative, API-driven approach, * Creates and provisions virtual machines and sets up Kubernetes, * Can scale and handle cluster upgrades, * Works with any cloud provider and with any operating system or image, * Depending on options available for a cloud provider, user can define how exactly instances and clusters will be provisioned, by providing a bootstrap script. Cons: * Project is still in prototype phase, meaning many breaking changes can get accepted over time, * There are still missing pieces, e.g. HA setups, * Not widely adopted. #### Cluster-API Concepts We've seen what Cluster-API is and what led to its creation. Let's now see how it actually works and how you can utilize it. First, we'll take a look at what resources define your cluster and machines and how Cluster-API "converts" those resources to actual virtual machines and Kubernetes clusters. A cluster is defined using the Cluster resource. By default, the Cluster resource Spec defines how networking is going to be set up—what CIRDs we are going to use and what domain name to use for services, and Cluster resource Status saves endpoint IP address and port. A machine is defined using the Machine resource. The Machine resource Spec defines what Kubernetes version is going to be used for that machine and what taints to set on that Kubernetes node, while the Machine resource Status stores IP address of that machine. Both Cluster and Machine resources can be extended by specific Cluster-API implementation to include information relevant for that cloud provider. For example if someone is working on AWS Cluster-API implementation, Cluster resource can be extended to include information about SecurityGroups, or in case of DigitalOcean how to create Cloud Firewall. Beside the main Cluster and Machine resources, we have several more resources that allow you to manage a bunch of machines, such as MachineSets similar to ReplicaSets and MachineDeployments similar to Deployments. Both allow you to define how many machines you want to create and when you create that one resource, Cluster-API will create the underlying Machine objects for each replica. MachineSets and MachineDeployments are the main resources used to scale your cluster. The question which arises here is what happens when a Cluster or Machine resource is created? How does the Cluster-API create a new cluster or machine? The component which handles this is a controller which reconciles all Cluster-API resources. The reconciliation process assumes watching for events on all Cluster-API resources and depending on a triggered event a specific function is invoked. For example, if a new Machine resource is created the controller will invoke the Create function, which depending on implementation will create a machine, install Kubernetes, and join node a cluster. #### Cluster-API Project Structure and Cloud Specific Implementations The Cluster-API itself is cloud-agnostic, i.e. it works on any cloud provider. But to be able to handle cloud resources, virtual machine creation, we need to implement specific API calls for that provider somewhere. The [`kubernetes-sigs/cluster-api`](https://github.com/kubernetes-sigs/cluster-api) contains everything needed to start with Cluster-API: API types, controller which reconciles resources, `clusterctl` CLI implementation. The cloud-specific API calls and mechanisms for setting up instances are not part of the core Cluster-API. Instead, Cluster-API just exposes interfaces that must be implemented. The cloud-specific Cluster-API implementations are called Cluster-API Providers. They contain implementations of Cluster-API interface functions, which handle creating, deleting, and upgrading cluster and machines, as well as contain other needed mechanisms such as a mechanism for provisioning machines. This approach has many positive sides: it ensures that anybody can import Cluster-API and build a Cluster-API provider for any cloud, using any API, for any setup. The Cluster-API team can focus on developing the core API as they don't need to spend countless hours on reviewing changes to the core repository for all the setups and cloud providers. At the time of writing this post, there are several available Cluster-API Providers, such as [AWS Provider](https://github.com/kubernetes-sigs/cluster-api-provider-aws), [GCP Provider](https://github.com/kubernetes-sigs/cluster-api-provider-gcp), [DigitalOcean Provider](https://github.com/kubernetes-sigs/cluster-api-provider-digitalocean). The [Cluster-API README](https://github.com/kubernetes-sigs/cluster-api#provider-implementations) contains the list of all known Cluster-API implementations. #### Getting Involved With Cluster-API Project The Cluster-API project is still a young project. The core part is implemented and there are Cluster-API Providers for the most popular cloud providers. But there are still many features missing that would make it easier to implement Cluster-API Providers as well as bring new possibilities. The Cluster-API project and Cluster-API Providers are looking for all kind of contributions, including but not limited to adding and improving feature set, improving testing and making sure it works correctly, writing documentation... To get started, head over to GitHub and check out the issue tracker. Try to find issues labeled as `good first issue`, as they're usually good for beginners. Here are some of Cluster-API projects that have some `good first issue`s: * [Cluster-API](https://github.com/kubernetes-sigs/cluster-api/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22) * [Cluster-API provider AWS](https://github.com/kubernetes-sigs/cluster-api-provider-aws/labels/good%20first%20issue) * [Cluster-API provider DigitalOcean](https://github.com/kubermatic/cluster-api-provider-digitalocean/labels/good%20first%20issue) If you have any question or would like to communicate with other Cluster-API users, contributors and leads, you can join #cluster-api channel on [Kubernetes Slack](http://slack.k8s.io/). The Cluster-API team is holding weekly sync-up meetings for all users and contributors that you can join. At the time of writing this post there are four Cluster-API meetings weekly: * Cluster-API Breakout - Wednesday 5:00 PM UTC. A meeting targeted for the core Cluster-API development * Cluster-API Implementers' Office Hours - US West Coast: Tuesday 7:00 PM UTC; EMEA: Wednesday 1:00 PM UTC. A meeting targeted to Cluster-API implementations, such as Cluster-API Providers * Cluster-API Provider AWS Office Hours - Monday 5:00 PM UTC. A meeting focused on Cluster-API Provider AWS development <br> --- ## ContainerDays Recap: 3 Days Full of Container Craziness - **URL:** https://www.kubermatic.com/blog/container-days-hamburg-recap/ - **Date:** 2026-05-07 - **Description:** Over 800 attendees came from around the world to hear talks from leading minds in the cloud native ecosystem. - **Categories:** Company - **Tags:** Announcements - **Authors:** Bill Mulligan Now in its third year and moved to the historic Hamburg Harbor Museum, ContainerDays 2018 was the perfect setting to discuss containers, microservices, Kubernetes, and cloud native tooling. Over 800 attendees came from around the world to hear talks from leading minds in the cloud native ecosystem including Craig McLuckie, co-founder of Kubernetes, Ihor Dvoretskyi from the CNCF, and Sandeep Dinesh, a developer advocate at Google. With one day of workshops and two days of sessions, many bottles of Club Mate and Fritz Cola were consumed by our team to keep everyone going strong. Day One workshops covered a range of topics from Basic Istio Playgrounds to Advanced Kubernetes Security. We were happy to run the Kubermatic classic, Kubernetes for Developers, hosted by our ever affable trainer Guus. Sessions kicked off on Day Two with a talk from Ursula Richenberger, of the German Port Museum Project, explaining how shipping containers transformed the transportation and logistics industry just as containers and Kubernetes are currently changing IT development and operations. Between attending talks and staffing the Kubermatic booth, the rest of the conference seemed to fly by. Outside the talks, both the free harbor boat tour and food trucks (no soggy sandwiches here) were real highlights that set ContainerDays apart from your average conference center conference. #### Where to learn more * [The NewStack Summary](https://us11.campaign-archive.com/?u=ab6c02b160780b8e6569144f8&id=ce7e13d77c) * [Blog post by Alexander Trost](https://edenmal.moe/post/2018/Container-Days-2018-Hamburg/) #### Kubermatic Talks #### Cloud Native Continuous Delivery for Kubernetes Seeking a better cloud native CI/CD experience? [Check out Matthias’ talk](https://www.youtube.com/watch?v=H2TEMO2NG2Y). #### What you’ll learn: * How Drone defines continuous delivery pipelines * How KubeCI creates a Kubernetes runtime of Drone * KubeCI roadmap for improvements #### Where to learn more #### * [Drone](https://drone.io/) #### Managing und Running Multiple Kubernetes Clusters Seeking a better Kubernetes experience? [Check out Simon and Henrik's talk](https://www.youtube.com/watch?v=kPIjBSnPbvw). #### What you’ll learn: #### * Common challenges running multiple Kubernetes clusters * Key features for a container engine * Lessons learned from running multiple Kubernetes clusters #### Where to learn more #### * [SysEleven MetaKube Managed Kubernetes](https://www.syseleven.de/en/products-services/kubernetes/) * [Kubermatic Kubernetes Platform Container Engine Documentation](https://docs.kubermatic.io/) #### Machine API: An easier way to manage nodes in Kubernetes #### Seeking a better node scaling experience? [Check out Sebastian’s talk](https://youtu.be/Sab_Ak3MAxU?list=PLHhKcdBlprMcVSL5OmlzyUrFtc7ib1V4w). #### What you’ll learn #### * Problems with scaling nodes manually or with CI/CD tools * How MachineController can automatically provision new nodes * How Machine classes, sets, and deployments ease Ops burden <iframe width="100%" height="350px" style="margin-top:36px; margin-bottom:36px;" src="https://www.youtube.com/embed/Sab_Ak3MAxU?list=PLHhKcdBlprMcVSL5OmlzyUrFtc7ib1V4w" frameborder="0" allow="autoplay;"></iframe> #### Where to learn more #### * [Cluster API](https://github.com/kubernetes-sigs/cluster-api) --- ## KubeCon Copenhagen: Monitoring with Prometheus - **URL:** https://www.kubermatic.com/blog/kubecon-copenhagen-multi-cluster-monitoring-with-prometheus/ - **Date:** 2026-05-07 - **Description:** Check out our recap of one great week in Denmark - **Categories:** Company - **Tags:** Events, Announcements - **Authors:** Julian Hansert KubeCon Europe is the premier Kubernetes conference in Europe. With 4,300 conference attendees, tripling Berlin just a year ago, K8s has clearly become the industry standard for container orchestration. With the event in Copenhagen, only a stone’s throw away from our headquarters in Hamburg, it was one that we could not miss. Our whole development team took the trip to engage with the community, discover new developments in the cloud native ecosystem, and see who could spot Kelsey Hightower first. Our booth received a flow of people wanting to learn about the Kubermatic Kubernetes Platform Container Engine and where they could get their hands on one of the famous Kubermatic hoodies (sorry team members only). We were blown away by the growth of the cloud native community (23,000 contributors and counting) and are excited to be a part of spreading the word. A key part of being a member of the community is upstream contribution to projects. We were very proud that Frederic Branczyk from RedHat and Kubermatic software engineer, Matthias Loibl, were able to present their work to make it simpler to deploy, manage, run, and monitor Prometheus on any infrastructure. Seeking a better monitoring experience? Check out their talk. #### What you’ll learn: * How Prometheus and the prometheus operator work * How to do declarative and federated Prometheus monitoring across Kubernetes clusters and data centers * How to do global and long term Prometheus monitoring with Thanos <iframe width="100%" height="350px" style="margin-top:36px; margin-bottom:36px;" src="https://www.youtube.com/embed/IpGfmmJ2hcw" frameborder="0" allow="autoplay;"> </iframe> #### Where to learn more #### <a href="https://github.com/coreos/prometheus-operator" target="_blank"> Prometheus Operator </a> <a href="https://github.com/improbable-eng/thanos" target="_blank"> Thanos - HA Prometheus with long term storage </a> <a href="/images/blog/2018-05-08/copenhagen1.jpg" target="_blank"> <img src="/images/blog/2018-05-08/copenhagen1.jpg" alt="Kubermatic team in Kopenhagen img#1" width="100%"/> </a> <a href="/images/blog/2018-05-08/copenhagen2.jpg" target="_blank"> <img src="/images/blog/2018-05-08/copenhagen2.jpg" alt="Kubermatic team in Kopenhagen img#2" width="100%"/> </a> <a href="/images/blog/2018-05-08/copenhagen3.jpg" target="_blank"> <img src="/images/blog/2018-05-08/copenhagen3.jpg" alt="Kubermatic team in Kopenhagen img#3" width="100%"/> </a> --- ## Kubermatic Among the First Kubernetes Training Partners - **URL:** https://www.kubermatic.com/blog/kubermatic-among-the-first-kubernetes-training-partners/ - **Date:** 2026-05-07 - **Description:** Kubermatic is one of the first six Kubernetes Training Partners worldwide. - **Categories:** Company - **Tags:** Events, Announcements - **Authors:** Kristin Wittig We are happy to announce that Kubermatic is one of the first six Kubernetes Training Partners (KTP) of the Cloud Native Computing Foundation (CNCF). The newly launched KTP was created to establish a tier of training providers with deep experience in cloud native technology training. It ensures that individuals or enterprises who are looking for training that maps directly to the Certified Kubernetes Administrator (CKA) and Certified Kubernetes Application Developer (CKAD) exams can choose from a list of KTPs with a proven track-record. The KTP represents an important step towards the professionalization and maturation of the Kubernetes ecosystem. As the adoption of Kubernetes accelerates, so does the demand from entreprises that need professional and reliable talent. As a KTP, we offer a wide range of certified Kubernetes trainings to organizations embarking on their journey towards cloud native applications. #### How did we become a KTP? To earn the KTP certification, beyond being a CNCF member and deeply involved in the cloud native community, we first needed to become a Kubernetes Certified Service Providers (KCSP) and a reseller of the CKA exam. Next, we needed to demonstrate strict benchmarks for experience and quality of our courses, including references from students and major organizations who have completed our trainings. Lucky us that we have a team of rockstar trainers to provide top notch trainings! #### Learn more #### [CNCF announcement](https://www.cncf.io/announcement/2018/05/02/cloud-native-computing-foundation-announces-new-partner-program-for-kubernetes-training-partners-ktp/) <a href="/services/trainings/" target="_blank">Kubermatic Trainings</a> --- ## Kubermatic now Kubernetes Certified Service Provider - **URL:** https://www.kubermatic.com/blog/loodse-now-kubernentes-cert-service-provider/ - **Date:** 2026-05-07 - **Description:** Kubermatic is now officially listed as a Kubernetes Certified Service Provider by the CNCF. - **Categories:** Company - **Tags:** Announcements - **Authors:** Kristin Wittig We are happy to announce that Kubermatic is now officially listed as a Kubernetes Certified Service Provider (KCSP) by the Cloud Native Computing Foundation (CNCF). The KSPC program was launched in September 2017 to accredit providers that have the necessary expertise to support enterprises in successfully adopting Kubernetes. It ensures that customers have a trusted partner at their site to support their individual use case. The KCSP represents an important step towards the professionalization and maturation of the Kubernetes ecosystem. As the adoption of Kubernetes accelerates, so does the demand from entreprises that need professional and reliable support. As a KCSP partner, we offer a wide range of Kubernetes related assistance: support, consulting, professional services and training for organizations embarking on their journey towards containerized applications. #### How did we become a KSPC? To achieve the KCSP, we needed at least three employees to pass the Certified Kubernetes Administrator (CKA) Exam. During a challenging 3 hour exam, our engineers had to solve a set of issues from a command line to prove that they have the required skills to be a successful Kubernetes Administrator in our industry today. Lucky us that all our engineers kept their nerves and did a great job! Congrats! Our thanks go to the Linux Foundation EMEA for their support! #### Learn more #### <a href="https://www.cncf.io/certification/kcsp/" target="_blank"> KCSP Website </a> <a href="https://training.linuxfoundation.org/?creative=241256148856&keyword=www.linuxfoundation.org%2F&matchtype=b&network=g&device=c&pi_ad_id=241256148856&gclid=EAIaIQobChMIzvmQ-66H2QIVa7HtCh1OTAiyEAAYASABEgLdY_D_BwE" target="_blank"> Linux Foundation’s Trainings </a> --- ## KubeCon Austin: Kubernetes in Hybrid Setups - **URL:** https://www.kubermatic.com/blog/kubecon-austin-multiple-kubernetes-clusters-in-hybrid-setups/ - **Date:** 2026-05-07 - **Description:** Check out our recap of a great week at KubeCon North America. - **Categories:** Company - **Tags:** KKP, Events, Announcements - **Authors:** Sebastian Scheele KubeCon North America is the premier Kubernetes conference of the year. Even though the snow in Austin was more like Hamburg in December than the weather some of us packed for (we’ll bring an extra hoodie for Henrik next year), this was an event we were sure not to miss. Sponsoring a startup booth gave us the chance to bring our Kubermatic Kubernetes Platform Container Engine (K8c) and the famous Kubermatic hectopus to the US. Besides meeting and exchanging with potential customers and other attendees, Simon Pearce from cloud provider SysEleven went on stage with our CEO, Sebastian, to present how we worked with their cloud team to quickly and effectively build a Managed Kubernetes. This case study was also perfect to showcase the advantages of using Kubermatic Kubernetes Platform’s Kubernetes on Kubernetes architecture to manage multiple Kubernetes clusters. Seeking a simpler Kubernetes experience? Check out their talk! #### What you’ll learn: * Common challenges of running multiple Kubernetes clusters * Key features for a container engine * Lessons learned from running multiple Kubernetes clusters <iframe width="100%" height="350px" style="margin-top:36px; margin-bottom:36px;" src="https://www.youtube.com/embed/IpGfmmJ2hcw" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe> #### You’ll be surprised by How running Kubernetes on Kubernetes makes a much more resilient system. <br> #### Where to learn more <a href="https://www.syseleven.de/produkte-services/managed-kubernetes/" target="_blank"> SysEleven MetaKube Managed Kubernetes </a> <a href="https://docs.kubermatic.io/" target="_blank"> Kubermatic Kubernetes Platform Container Engine Documentation </a> --- ## Introducing Kubermatic Kubernetes Platform 2.0 - **URL:** https://www.kubermatic.com/blog/introducing-kubermatic-kubernetes-platform-2/ - **Date:** 2026-05-07 - **Description:** The new release facilitates automated Kubernetes management in the cloud and on-prem. - **Categories:** Products - **Tags:** KKP, Events - **Authors:** Kristin Wittig On the occasion of KubeCon North America, we are excited to announce the release of Kubermatic Kubernetes Platform Container Engine 2.0. The new release includes a number of improvements and features that make it even easier to setup, deploy and manage a Kubernetes environment in the cloud, on-prem and in hybrid scenarios. Kubermatic Kubernetes Platform Container Engine 2.0 features cover: * Integration of Microsoft Azure, TelekomCLOUD, Google Cloud Platform, Huawei and OpenStack * Certified 1.8 Kubernetes distribution with automated cluster upgrades and support of CustomResourceDefinitions * Centralized user management with support of groups and roles and SSH key management across all supported providers * Integration of <a href="https://github.com/kube-node/nodeset" target="_blank">nodeset/nodeclass</a> with automated cluster scaling * Integration of <a href="https://github.com/projectcalico/canal" target="_blank">Canal</a> with policy-based networking * Dashboard version 2 #### Extended Cloud Provider Support It is your specific use-case that defines the ideal Kubernetes setup: in private and/or public cloud, on-prem or in hybrid scenarios. Kubermatic Kubernetes Platform makes it easy to deploy and manage multiple clusters on your preferred infrastructure by supporting major public cloud provider including AWS, Digital Ocean, OpenStack, GCP, Huawei, TelekomCLOUD, Microsoft Azure, VMware as well as bare metal. <br> <a href="/images/blog/2017-12-06/create-cluster.png" target="_blank"> <img src="/images/blog/2017-12-06/create-cluster.png" alt="create-cluster" width="100%"/> </a> <br> #### Certified Kubernetes 1.8 Distribution and Automated Cluster Upgrades The new release enables you to always run the latest upstream version of Kubernetes without needing manual intervention. You simply decide to update your cluster and Kubermatic Kubernetes Platform does everything for you. <br> <a href="/images/blog/2017-12-06/upgrade-cluster.png" target="_blank"> <img src="/images/blog/2017-12-06/upgrade-cluster.png" alt="upgrade-cluster" width="100%"/> </a> <br> #### Centralized User Management Thanks to centralized user management, users can easily access the cluster via the Kubernetes API. Kubermatic Kubernetes Platform enables you to define roles and groups so you can set-up dedicated clusters for each team. #### Automated Cluster Scaling With the integration of <a href="https://github.com/kube-node/nodeset/" target="_blank"> nodeset</a>, you can scale your Kubernetes clusters up and down by simply setting the number of desired nodes while Kubernetes itself takes care of the rest. This enables you to add and delete nodes without manual intervention, regardless of the underlying provider. <br> <a href="/images/blog/2017-12-06/add-node.png" target="_blank"> <img src="/images/blog/2017-12-06/add-node.png" alt="add-node" width="100%"/> </a> <br> Read more about Kubernetes auto-scaling using <a href="https://thenewstack.io/kube-node-let-k8s-cluster-auto-manage-nodes/" target="_blank"> kube-note </a>. #### Policy-Based Networking With the new release, you now have access Canal’s fine-grained network policies offering you the highest standard of security for your cloud native applications. #### Dashboard Version 2 The new Kubermatic Kubernetes Platform dashboard leads users intuitively through the entire deployment process to eliminate potential pitfalls and comes with an attractive look-and-feel. #### Where to learn more [Request a Demo of Kubermatic Kubernetes Platform](/demo/) --- ## Kubermatic Kubernetes Platform Now Certified by the CNCF - **URL:** https://www.kubermatic.com/blog/kubermatic-now-kubernetes-certified/ - **Date:** 2026-05-07 - **Description:** Kubermatic Kubernetes Platform Container Engine is one of the first certified Kubernetes distributions worldwide. - **Categories:** Products - **Tags:** KKP - **Authors:** Kristin Wittig Today, we are excited to announce that the Kubermatic Kubernetes Platform Container Engine, our enterprise-ready multi-cluster platform, has been accepted as one of the first Certified Kubernetes offerings worldwide by the Cloud Native Computing Foundation. With the Kubermatic Kubernetes Platform Container Engine, our goal was to empower businesses to easily deploy and manage containerized workloads in the cloud or on-prem by using pure upstream Kubernetes. Certification gives customers certainty that the Kubermatic Kubernetes Platform API functions as specified and guarantees for interoperability and portability to any K8s environment. Moreover, with strong guarantees for regular updates on the latest Kubernetes version, users can be confident they always benefit from the most recent community features. #### What is Certified Kubernetes and why does it matter? With more and more Kubernetes offerings coming to market, the <a href="https://www.cncf.io/certification/software-conformance/" target="_blank"> Certified Kubernetes Conformance Program</a> is an important step to professionalizing the Kubernetes ecosystem and accelerating Kubernetes adoption. It was launched by the CNCF to provide a reliable quality indicator for Kubernetes offerings. The conformance definition and mechanics of the conformance test are specified by two Special Interest Groups of the CNCF End User Technical Advisory Board. All vendors following the conformance definition can run the performance test and submit their results to the CNCF for review. After certification they are allowed to display the Certified Kubernetes logo. #### Where to learn more <a href="https://www.cncf.io/announcement/2017/11/13/cloud-native-computing-foundation-launches-certified-kubernetes-program-32-conformant-distributions-platforms/" target="_blank"> CNCF Announcement </a>