Skip to content

Add Configuration Maximums page for Kubermatic Virtualization#2190

Open
mihiragrawal wants to merge 1 commit into
kubermatic:mainfrom
mihiragrawal:configmax-configuration-maximums
Open

Add Configuration Maximums page for Kubermatic Virtualization#2190
mihiragrawal wants to merge 1 commit into
kubermatic:mainfrom
mihiragrawal:configmax-configuration-maximums

Conversation

@mihiragrawal
Copy link
Copy Markdown

What

New documentation page: Configuration Maximums for Kubermatic Virtualization, under content/kubermatic-virtualization/main/configuration-maximums/. It documents the validated configuration maximums of a KubeV cluster — VMs, networks, firewall rules, subnets, routes, etc. — as discovered by the in-cluster ConfigMax benchmark tool.

Lands in main (next release); v1.1.0 is frozen.

What's in it

  1. Validated maximums — customer-facing table. Embargo-clean (no VMware/vSphere naming). Uses an Accepted (objects stored) vs Sustained (objects in place while VM-to-VM latency stayed within 5 % of baseline) split so the headline numbers stay visible but honest.
  2. Engineering reference — internal table with the full VMware vSphere ConfigMax comparison and measurement provenance. Marked as internal / may be trimmed before public release.
  3. How we measure — discovery / target / workload-SLO run modes + the distress signals that stop a run.
  4. What each number is limited by — one-line bottleneck per capability.
  5. Run it yourself — prerequisites, one annotated ConfigMaxRun YAML, apply/watch/read commands, and a key-parameters reference.

For the reviewer (@Moath — decisions needed)

  • Engineering table: keep it on the public page, or trim to the customer table only?
  • "Validation in progress" rows (attachment templates, routable services, QoS policies, VMs-per-host): include now or omit until re-validated?
  • Any numbers to soften before this is customer-visible.

Verification

Built locally with the project's Dockerized Hugo (quay.io/kubermatic/hugo:0.159.1-0), exit 0, no errors. Page renders and appears in the main section nav.

🤖 Generated with Claude Code

Document the validated configuration maximums of a KubeV cluster as
discovered by the ConfigMax benchmark tool. Includes:

- a customer-facing "Validated maximums" table (accepted vs sustained),
- an internal engineering reference with the vSphere ConfigMax comparison
  and full measurement provenance (marked for review/trim),
- a "How we measure" section covering discovery / target / workload-SLO
  modes and the distress signals that stop a run,
- a per-capability bottleneck summary,
- a "Run it yourself" guide with an annotated ConfigMaxRun YAML and the
  key parameters reference.

Lands in content/kubermatic-virtualization/main (next release).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@kubermatic-bot kubermatic-bot added dco-signoff: yes Denotes that all commits in the pull request have the valid DCO signoff message. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Jun 3, 2026
@kubermatic-bot
Copy link
Copy Markdown
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign iammerus for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dco-signoff: yes Denotes that all commits in the pull request have the valid DCO signoff message. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants