kubernetes / kubernetes/perf-tests

Request for review: semantic admission/APF evaluation harness

Open
#4,014 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
989
Forks
654
Avg merge
3d 12h
Merged PRs (30d)
56

Description

Hello Kubernetes perf-tests / SIG Scalability maintainers,

This is a request for review of a third-party evaluation harness for a semantic consistency kernel called MST-NF. It is intentionally framed as a benchmark-mapping and artifact-review request, not as an upstream merge request.

Public artifact:

- Repository path: https://github.com/minustwo/codex-proof-workbench/tree/codex/medusa-mstnf-kernel/runtime/k8s-admission-consistency-kernel
- Reproduction entrypoint: `npm run verify`
- Sonobuoy wrapper: https://github.com/minustwo/codex-proof-workbench/tree/codex/medusa-mstnf-kernel/runtime/k8s-admission-consistency-kernel/sonobuoy
- Scope: safe in-process Kubernetes-style admission/quota/APF evaluation harness

Boundary statement:

This is not a benchmark of Kubernetes production core. It is not kube-apiserver production core, not scheduler production core, not etcd behavior, not a real admission webhook, and not a real cluster workload benchmark. It does not invoke kube-apiserver admission, scheduler, kubelet, etcd, webhook, container runtime, or production Kubernetes control-plane paths. The Sonobuoy wrapper uses Kubernetes only as a standard test carrier.

The artifact tests high-concurrency Kubernetes-style admission traffic over this canonical lane:

```text
namespace:resourceClass:timeWindow
```

The current artifact checks:

- useful admissions are preserved
- backend attempts are reduced
- CAS conflicts, retries, duplicate backend attempts, and priority inversions are eliminated in the MST-NF treatment
- replay divergence is zero
- seed-sweep invariant failures are empty
- Kubernetes-style AdmissionReview projection is present
- Kubernetes-style ResourceQuota projection is present
- Kubernetes APF-style FlowSchema and PriorityLevelConfiguration projections are present
- APF-style flow classification, queue-key projection, fair-queue shape, and response-header shape are checked
- priority/preemption fixture passes
- APF-style priority isolation fixture passes
- Sonobuoy Job plugin wrapper is available for Kubernetes-cluster-carried reproduction

Reviewer commands:

```bash
npm run verify
npm run sonobuoy:smoke
```

The Sonobuoy wrapper can also be built and run from the artifact directory:

```bash
docker build -f sonobuoy/Dockerfile -t mstnf-k8s-admission-sonobuoy:local .
sonobuoy run \
--plugin sonobuoy/mstnf-k8s-admission-plugin.yaml \
--plugin-image mstnf-k8s-admission=mstnf-k8s-admission-sonobuoy:local \
--wait
```

Key docs in the artifact:

- `BENCHMARK_NOTES.md`
- `docs/EXTERNAL_K8S_SOURCE_MAP.md`
- `docs/ACCEPTANCE_CRITERIA.md`
- `docs/REPRODUCIBILITY.md`
- `docs/THIRD_PARTY_REVIEW.md`
- `sonobuoy/README.md`

Requested feedback:

- Is this a fair Kubernetes-adjacent evaluation mapping for admission/quota/APF-style traffic?
- Are the AdmissionReview and ResourceQuota projections useful external anchors?
- Is the APF FlowSchema / PriorityLevelConfiguration projection useful for reviewing priority isolation and fair-queue classification?
- Are the priority/preemption and APF fixtures fair enough for an admission-control benchmark?
- Would a ClusterLoader2-compatible wrapper be the right next step if this were to move closer to kubernetes/perf-tests conventions?
- Are the boundary clauses clear enough to avoid confusion with production Kubernetes core benchmarking?

Thank you for any guidance on whether this artifact belongs near perf-tests, should stay as an external artifact, or should be reshaped before further review.

Contributor guide

Open the contributing guide

Research direction

Start with the linked external artifact and its `npm run verify` and `npm run sonobuoy:smoke` entry points, then read `BENCHMARK_NOTES.md`, `docs/EXTERNAL_K8S_SOURCE_MAP.md`, and `docs/ACCEPTANCE_CRITERIA.md`. Review whether the AdmissionReview, ResourceQuota, APF, and Sonobuoy mappings are appropriate for perf-tests; done means providing a maintainer decision or concrete guidance on placement and scope.

Written by the indexing model from the issue text.

Assessment

Tech stack
kubernetes
Domain
devops, testing
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.