We’re happy to announce the release of Kubermatic Kubernetes Platform (KKP) 2.31.
Over the past months, we’ve focused on making KKP easier to operate at scale, especially for organizations running AI workloads and multi-tenant Kubernetes platforms. This release introduces GPU project quotas, completes the transition to Gateway API, expands identity management, and delivers several improvements across providers, operations, and the dashboard.
Here’s everything that’s new.
AI Infrastructure: GPU Project Quotas (Enterprise Edition)
GPU resources are often the most expensive part of a Kubernetes platform, but until now they couldn’t be managed through KKP’s project quota system.
KKP 2.31 introduces GPU project quotas for KubeVirt environments, allowing platform teams to manage accelerator capacity alongside CPU and memory using the same familiar quota mechanism. With this release, you are now able to:
- Set GPU limits per project
- KKP automatically counts the actual accelerator resources requested by machine types
- Existing quotas continue to behave as before unless GPU quotas are explicitly configured
This feature is currently an early-stage Enterprise Edition capability for KubeVirt and must be enabled explicitly.
Flexible Identity Management for Multi-Tenant Platforms
Connecting an identity provider to one cluster used to mean changing global configuration, so a single customer’s request became everyone’s change. In KKP 2.31, managing authentication across multiple tenants is significantly more flexible.
You can now configure identity providers per cluster, per datacenter, or globally, with the most specific setting taking precedence. This allows service providers to give each tenant its own login configuration without affecting anyone else.
Administrator access can follow your directory too: map groups from your identity provider to KKP administrator rights, and membership is granted and revoked automatically (Enterprise Edition). Administrators who were promoted manually remain unchanged.
Gateway API Is the Only Ingress Path Now
The Kubernetes project is retiring the ingress-nginx controller, and once that happens, there are no more upstream security fixes for it. Staying on it means an audit finding you cannot close and a vulnerability you cannot patch, and the platform team carries that risk for every application behind the ingress. KKP 2.30 let you migrate when you were ready. 2.31 completes the move.
The installer now sets up the gateway controller every time, and KKP manages the gateway itself, so a fresh install works with no flags to remember. Old migration flags still exist and do nothing, so existing automation keeps running, and a cleanup option removes the leftover nginx-ingress deployment and its load balancer. If your organization already runs its own gateway, KKP will route through it and leave it alone rather than insisting on owning one. The upgrade path from 2.29 and 2.30 is covered by automated tests against real released builds.
Current Versions and Safer Operations
KKP 2.31 keeps the platform aligned with the latest supported upstream versions:
- Kubernetes 1.36 is now supported
- Kubernetes 1.35.7 becomes the default version
- Kubernetes 1.32 is no longer supported
- Cilium 1.19.4 becomes the default for new clusters.
The release also includes several operational improvements:
- Schedule core KKP components on specific nodes or across availability zones
- Use existing secret management systems for chart credentials
- Hide an audit option for individual datacenters
- Reduce memory usage for user-cluster monitoring
Cloud Provider Improvements
KKP 2.31 includes several practical improvements across supported providers and day-to-day operations:
- OpenStack: Supports automatic image selection based on the operating system.
- Azure: Adds support for Trusted Launch virtual machines
- Machine Controller: Failed machine creations now report clearer failure reasons
- Dashboard: Configure proxy settings per cluster
Breaking Changes and Action Required
If you use HTTP01 certificate challenges, update your issuer configuration before upgrading so the challenge points at the new gateway route rather than the old ingress class. This is the one change that stops certificates being issued if you miss it. Afterwards, run the installer’s cleanup option to remove the old ingress deployment and its load balancer.
The default login client identifier has changed. Dashboard login, Kubernetes dashboard login, and kubeconfig access now share a single identity client using a more secure login flow. Your identity provider configuration and your KKP configuration must be updated together, because the client and its secret are now checked as a pair.
Kubernetes 1.32 is no longer supported, so move any remaining 1.32 clusters up first and check your clusters against the reduced list of supported Cilium versions. Air-gapped installations need to regenerate their mirror lists, because several Azure components moved to a new registry path and new charts were added.
Deprecations
The following items are now deprecated:
- Gateway API migration flags: The legacy migration flags are still accepted for compatibility but no longer have any effect.
- Older Cilium versions: Superseded Cilium versions have been removed from the supported version matrix.
We recommend removing deprecated flags from automation pipelines during your next maintenance cycle.
How to Upgrade
Update your certificate issuer and identity provider configuration first, since those are the two things that break if skipped. Then upgrade the master, upgrade each seed, and run the installer cleanup for the old ingress. Offline installations should refresh mirror lists before starting. The KKP documentation has the upgrade guide and the full migration steps.
Have a good time trying out the new features!
If you’re building AI infrastructure, GPU project quotas are a great place to start. Enable the feature in a test environment, assign a GPU quota to a project, and see how KKP manages accelerator capacity alongside CPU and memory using the same familiar quota system.
Thank you for being a part of the Kubermatic community, and we look forward to your feedback on KKP 2.31. You can find more details about this release in the changelog. 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 form.
