Kubernetes for AI agents: when code is cheap, proof matters

A March 2026 DORA analysis of AI tensions found engineers are reallocating time saved on code production to auditing and verification, with greater AI adoption associated with higher delivery throughput but also greater instability, according to the article. The piece argues that Kubernetes, Cluster API, Argo CD and Model Context Protocol (MCP) can be combined so each candidate change becomes a bounded experiment with its own identity, resources, evidence and end time, rather than competing for one shared staging environment. It cites METR's February 2026 update as suggesting newer tools probably deliver more benefit than its early-2025 study captured, while noting selection effects prevent a reliable new estimate.

It is 09:07 on Monday. Imagine a team of six developers opening enough pull requests to keep an entire engineering department busy. Their coding agents have worked through the weekend. There are new features, dependency upgrades, database migrations and an ambitious rewrite of the checkout service. By 09:15, the team's shared staging environment is broken. Nobody knows which change broke it. The code is arriving faster than the organisation can establish whether it works. This is where Kubernetes becomes interesting again. Kubernetes runs and coordinates containerised workloads. Cluster API extends that approach to creating and managing Kubernetes clusters. Argo CD keeps applications aligned with configuration stored in Git. And Model Context Protocol MCP gives AI applications a common way to discover and call tools, including tools that inspect or change infrastructure. Together, these components can give a small team an extraordinary capability: an AI can request an environment, run an experiment, inspect the evidence and release the resources. The opportunity is bigger than asking Claude or ChatGPT why a Pod is crashing. We can build platforms where every significant change gets the infrastructure it needs to prove itself, and where verification continues after the humans go home. The scarce resource is becoming confidence. The next great developer platform will manufacture it. The queue moves to QA For years, software organisations optimised the journey from an idea to working code. Agentic development, in which software agents plan, implement and revise changes across multiple steps, compresses parts of that journey. It also moves the queue downstream. A developer can launch several implementations before a reviewer has understood the first one. The problem is already visible in research. DORA's March 2026 analysis of AI tensions https://dora.dev/insights/balancing-ai-tensions/ describes engineers reallocating time saved in code production to auditing and verification, alongside an association between greater AI adoption, higher delivery throughput and greater instability. Faster production does not automatically produce a healthier delivery system. Ten times the output is a useful design challenge, not an established productivity multiplier for every developer. METR's February 2026 update https://metr.org/blog/2026-02-24-uplift-update/ suggests newer tools probably deliver more benefit than its early-2025 study captured, while explaining why selection effects prevent a reliable new estimate. For this article, imagine a team that can submit ten times as many plausible changes. Its platform has to cope even if only a fraction deserve to ship. QA now needs parallel environments, realistic data, browser sessions, API tests, migration rehearsals, security checks, failure injection and enough observability to distinguish a bad change from a bad test. Human reviewers still have to judge architecture, intent and product behaviour. Giving them a larger stack of green ticks is insufficient if those ticks were produced by the same mistaken assumptions that generated the code. One shared staging environment turns this abundance into contention. Teams queue for a database, overwrite each other's fixtures and spend the afternoon investigating failures they cannot reproduce. The platform needs to change its unit of work: each candidate change becomes a bounded experiment with its own identity, resources, evidence and end time. Ask for an outcome, then let the platform do the work Our developer, Maya, starts with a request: Verify the checkout change against the current release. Exercise the database migration with old and new application versions running together. Check duplicate payment callbacks, slow database responses and rollback. Keep the experiment within the team's test budget and remove the environment afterwards. That is a much better interface than a ticket asking for three machines. It says what must be learned. The agent can inspect the repository, choose an approved test profile, request the environment and explain what it found. Platform teams should start designing for this as a normal way to use Kubernetes. Developers will increasingly interact through intent, constraints and evidence. Platform engineers still need direct tools for designing the system, inspecting failures and recovering it. But routine infrastructure work can become a conversation backed by an API, with the same capabilities available to a background worker. MCP supplies the connection between the AI application and its tools https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture . It does not supply your organisation's environment catalogue, durable job scheduler or permission policy. A useful platform tool might offer request environment , run verification , get evidence and release environment . Those are proposed organisation-specific operations, not standard MCP tool names. Behind them, reuse the infrastructure automation you already trust. If your platform already provisions environments through a service or workflow, expose that capability. The valuable new work is giving an agent a small, understandable contract with limits it cannot negotiate away. The Kubernetes MCP servers you can actually use The tooling has moved beyond a hypothetical chat interface. The following projects expose useful parts of this system today. They have different scopes and security defaults, so evaluate the release and tools you intend to enable. Application diagnostics: containers/kubernetes-mcp-server The containers Kubernetes MCP server https://github.com/containers/kubernetes-mcp-server/tree/v0.0.67 exposes Kubernetes resources, logs, Helm operations and multiple-cluster access through a native API client. It is a practical candidate for questions such as why a preview is unhealthy or which resource is preventing a rollout. Its configuration https://github.com/containers/kubernetes-mcp-server/blob/v0.0.67/docs/configuration.md supports read-only mode, tool filtering and denied resource types. Read-only is not the default in this release. Start with explicitly enabled observation tools, exclude Secrets and give the downstream identity only the Kubernetes permissions it needs. Fleet access: Giant Swarm's Kubernetes MCP server Giant Swarm's mcp-kubernetes https://github.com/giantswarm/mcp-kubernetes/tree/v1.11.2 can discover workload clusters through Cluster API and route operations across that fleet. This matters when an agent needs to inspect the particular cluster created for a test. Its RBAC design https://github.com/giantswarm/mcp-kubernetes/blob/v1.11.2/docs/rbac-security.md describes impersonation and identity propagation. Inspect both the management-cluster discovery permissions and the workload-cluster identity. Fleet discovery is distinct from provisioning the fleet. Cluster lifecycle: Giant Swarm's Cluster API MCP server Giant Swarm's mcp-capi https://github.com/giantswarm/mcp-capi/tree/v0.5.41 exposes cluster and machine inspection alongside lifecycle operations. Version 0.5.41 defaults to read-only access, enables a guard against modifying recognised GitOps-managed objects, and disables kubeconfig export. Here is the detail that changes the architecture: its capi create cluster handler https://github.com/giantswarm/mcp-capi/blob/v0.5.41/pkg/mcp/handlers/cluster.go L108 creates a Cluster object and tells the caller that infrastructure, control-plane and worker resources must be created separately. The release documentation also labels several provider-specific tools as placeholders. A tool named “create cluster” is therefore not evidence of complete, turnkey provisioning. For the workflow in this article, the platform must supply the complete approved configuration. Deployment context: Argo CD MCP Argo CD MCP from argoproj-labs https://github.com/argoproj-labs/mcp-for-argocd exposes applications, resource trees, events and logs, as well as mutation tools such as synchronisation and deletion. It helps an agent connect a failing service to the deployment that produced it. Use an Argo identity with the intended project permissions. Its credential documentation https://github.com/argoproj-labs/mcp-for-argocd providing-argocd-credentials distinguishes inbound access to the MCP server from the token it uses to reach Argo CD. Supplying an Argo token is not, by itself, authentication for callers of the MCP endpoint. These are building blocks for evaluation, not a requirement to install four servers. A team might begin with one diagnostic server and its existing deployment workflow. Pin the server version, inspect the exposed tool list, test denied operations and confirm which identity reaches Kubernetes. A “non-destructive” mode can still allow writes; read-only access can still reveal sensitive data. Give the agent a catalogue of environments Maya's agent should not have to invent a network, choose arbitrary machine sizes or decide which service account looks powerful enough. The platform team packages those decisions into a few versioned profiles, extending the standard application path https://kubedex.com/kubernetes-platform-golden-path/ it already supports. | Choose the smallest environment that can answer the question | | | |---|---|---| | Environment | Useful for | Boundary to understand | |---|---|---| | Namespace in a shared test cluster | Ordinary application previews, API contracts and most integration tests. | Shared control plane and nodes. Requires explicit access, network and resource policies. | | Sandboxed execution environment | Agent workspaces, generated code, browser automation and short experiments. | Isolation depends on the configured runtime, filesystem, credentials and network access. | | Virtual cluster | A separate Kubernetes API and space for cluster-scoped resources without a dedicated physical cluster. | Host networking and execution may still be shared; validate the implementation's isolation model. | | Disposable Cluster API cluster | Kubernetes upgrades, node behaviour, network or storage plugins, and tests requiring a full cluster boundary. | Provisioning latency, provider quotas and cloud cleanup become part of the experiment. | Kubernetes' multi-tenancy guidance https://kubernetes.io/docs/concepts/security/multi-tenancy/ explains why namespaces and virtual control planes need additional isolation controls. An external contributor's code should not inherit the trust given to your platform controllers. A namespace name is not a security boundary for hostile code. For full clusters, keep Cluster API and its infrastructure-provider controllers in a durable management cluster. Give them provider credentials with a defined scope, maintain backups and establish recovery ownership. Application experiments belong in workload clusters that can disappear without deleting the system that owns their lifecycle. The Cluster API quickstart https://cluster-api.sigs.k8s.io/user/quick-start describes this management/workload distinction. A cluster profile should fix the provider, region, Kubernetes version, machine-image versions, network and storage configuration, permitted node sizes, maximum node count and bootstrap policies. Let the agent select validated variables. For example, an upgrade experiment can request the approved “next Kubernetes version” profile rather than invent a version/provider combination. ClusterClass https://cluster-api.sigs.k8s.io/tasks/experimental-features/cluster-class/write-clusterclass can package reusable infrastructure, control-plane and worker templates with variables. It needs a precise maturity label: in the inspected Cluster API v1.14.3 feature gates https://github.com/kubernetes-sigs/cluster-api/blob/v1.14.3/feature/feature.go , managed topology remains alpha and disabled by default. Enable and validate it with your selected providers, or use complete provider templates your platform already supports. The environment contract can stay consistent while its implementation develops. Each profile also needs a data plan. Seed synthetic or properly sanitised fixtures, record their version, isolate each test's state and give external dependencies explicit test endpoints. A realistic checkout test must not send a real payment, email a customer or reuse production credentials. Database size, cardinality and migration history can matter as much as the Kubernetes configuration. Follow one change from request to evidence The following is an illustrative request to an organisation's platform tool, not a manifest or an existing MCP server's schema: { "operation": "request environment", "request id": "checkout-pr-418-attempt-1", "profile": "checkout-migration-v3", "candidate revision": "<full immutable commit SHA ", "baseline revision": "<full immutable commit SHA ", "fixture": "checkout-synthetic-v8", "suite": "migration-and-rollback-v5", "lease minutes": 45 } The authenticated caller determines ownership. Server-side policy validates the profile, revisions, fixture, maximum lifetime, concurrency allowance and estimated cost before admitting the request. A retry with the same request identity returns the existing experiment; it must not create another cluster. The response gives an operation ID, current state, expiry and evidence location. A durable workflow can continue when the chat closes. First, record and provision. Store the admitted request and its approved desired state. Where a complete cluster is required, the platform renders the provider resources or managed topology. A reconciler such as Argo CD applies that desired state to the management cluster; Cluster API and the provider controllers perform provisioning. Record failure conditions and deadlines rather than letting an agent repeatedly guess whether it should try again. Then, make it usable. Wait for the API, nodes, network and DNS to work. Bootstrap the approved policies and add-ons before exposing application access. Creating a CAPI cluster does not automatically register it with Argo CD: platform automation must establish the restricted deployment identity and register the cluster https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/ clusters . Credentials belong in that controlled integration, outside the model's conversation. Deploy the exact candidate. Argo CD's pull-request ApplicationSet generator https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Generators-Pull-Request/ can discover matching pull requests and supply the head commit SHA to application templates. For a responsive preview, configure authenticated webhook delivery rather than relying only on its default 30-minute polling interval. Keep the Argo project, repositories and deployment destinations under platform control. Untrusted pull-request fields must not choose their own privileges. Use immutable application revisions and image digests. An ApplicationSet can create the deployment records, but someone still has to supply the target environment and its policies. Its generated application is not proof that the database is ready or that the checkout works. Run the experiment. Seed the fixture and execute the approved tests through your CI system, Kubernetes Jobs or Argo Workflows, which runs multi-step jobs and is a different project from Argo CD. Launch independent tests in parallel. Give state-changing tests separate data or explicit sequencing. Save raw results before an agent summarises them. Explain the result. The evidence bundle should identify the candidate and baseline revisions, image digests, profile version, fixture version, test definitions, raw output, traces, relevant screenshots, failures and retries. Distinguish “the change failed its test” from “the environment failed to start” and “the test did not run”. Record the agent/model and tool versions used for investigative decisions so an operator can reconstruct the process. Finally, release the environment. Keep the evidence beyond the environment's lifetime. The user receives a result with a teardown status, not a reassuring paragraph while a forgotten load balancer continues billing. QA designs the experiments In our Monday story, the migration passes on a clean database. Under the mixed-version test, however, an old worker consumes a message written by the new application and processes it twice. Maya's agent retrieves the trace, builds a minimal reproduction and proposes a fix. The platform reruns the same immutable scenario against the revised candidate and the baseline. This is the leverage worth pursuing: the team can afford to ask more difficult questions before customers answer them. QA becomes the owner of those questions. Maintain acceptance criteria, invariants and regression tests independently of the implementation. An agent can generate tests, but it must not silently redefine success by deleting a failing assertion. A second agent offers another perspective; it does not guarantee independent reasoning if it receives the same flawed specification. For checkout, useful invariants include one charge per accepted order, no cross-customer data access, recoverable interruption and compatible behaviour during rolling deployment. Test refusal as well as success: expired credentials, duplicate callbacks, malformed input, missing dependencies and partial failure. Keep a human-owned release gate for the outcomes that matter. Give exploratory agents a separate lane. They can search for unexpected interactions, generate adversarial inputs and attempt to break assumptions in disposable environments. When they find a defect, reduce it to a reproducible regression test and review it into the maintained suite. That converts each investigation into a lasting improvement in the platform's ability to verify future changes. Parallel pull requests also interact. Ten individually green branches can combine into one broken release. Reverify the actual merge candidate, and select broader combinations where changes touch shared contracts, schemas or infrastructure. Test selection can reduce cost, but an agent's explanation of why a test is unnecessary is not equivalent to evidence that the release is safe. The work that continues after everyone goes home The same platform can serve a developer's conversation, a scheduled agent, or a persistent work process sometimes described as a “dot” or a run-forever agent. These are ways to initiate work. The infrastructure should continue to use durable state, bounded runs and clear ownership. | Separate the trigger from the authority to act | | | |---|---|---| | Work | Trigger and execution | Useful result and limit | |---|---|---| | Change verification | Pull request or merge candidate starts a queued workflow. | Evidence for the exact revision; concurrency cap, timeout and environment expiry. | | Upgrade and recovery rehearsals | Scheduled runs test dependency updates, cluster profiles, backup restoration and rollback. | A reproducible report or proposed change; synthetic data and bounded infrastructure. | | Exploratory QA | A background worker investigates a prioritised list of risks. | New reproducible failures; a fixed experiment and token budget, with diminishing returns as a stop condition. | | Lease and cost reconciliation | A deterministic controller regularly compares desired state, leases and actual resources. | Expired environments removed, leftovers escalated; cleanup does not depend on an AI session. | | Interactive diagnostics | A developer asks why a preview is pending or requests a failure replay. | A scoped explanation or short-lived reproduction; no access to unrelated teams' workloads. | | SRE investigation | An alert or operator request starts evidence gathering. | Timeline, hypotheses and a proposed response; production changes follow the approved runbook and release policy. | Maya can ask for one migration rehearsal now; the same capability can exercise the supported database and platform combinations overnight, then bring her the failures that need a decision. A persistent service does not require an endlessly thinking model. Let controllers watch state and queues hold work. Invoke reasoning when an event needs interpretation. Kubernetes Jobs provide deadlines and retry limits https://kubernetes.io/docs/concepts/workloads/controllers/job/ ; Argo Workflows supplies synchronisation controls https://argo-workflows.readthedocs.io/en/latest/synchronization/ for limiting concurrent work. Set limits across the service as well as inside each run. Twenty workflows with a limit of ten can still produce two hundred simultaneous tasks. The difficult part of “run forever” is surviving interruption. Persist checkpoints, deduplicate events, make infrastructure requests idempotent and bound retries. If a provider is unavailable or the same test keeps failing, record the state and escalate instead of repeatedly purchasing another attempt. For SRE, start with the agent collecting relevant changes, metrics, logs and traces using scoped read access. It can reproduce a suspected failure in a disposable environment and return a tested response proposal. Grant automatic remediation only for explicitly defined actions with preconditions, limits and verification. An incident should not become an opportunity for an agent to improvise new production privileges. The permissions that make autonomy possible Useful autonomy comes from knowing what the system will permit. A developer should be able to launch a standard test environment without finding an administrator, because the platform has already decided its allowed size, lifetime and access. Make the boundaries concrete: - Identity: retain the initiating person, agent and experiment in audit records. Separate inspection, environment creation and deployment identities. Use short-lived credentials; test workloads without an API requirement should not receive a service-account token. Kubernetes documents the options in its service-account guidance https://kubernetes.io/docs/concepts/security/service-accounts/ . - Execution: enforce Pod Security, approved service accounts, resource requests and limits, and allowed images through admission policy. Restrict privileged containers, host access and dangerous mounts. Permission to create workloads can indirectly grant access to credentials those workloads may mount, as the RBAC good-practices guide https://kubernetes.io/docs/concepts/security/rbac-good-practices/ explains. - Network and data: apply default-deny ingress and egress policies with a network implementation that enforces them. Allow only required DNS, registries, model endpoints, telemetry and test dependencies. Limit what logs and tool responses can send to a model provider; read-only access is still data access. - Tool authority: validate arguments at the service boundary. Tool output, repository content and logs are untrusted observations, never permission to expand the next action. The platform checks identity, environment ownership and allowed operation even when the model asks confidently. - Production: keep persistent changes in the approved deployment path, with an attributable diff and appropriate review. Disposable experiments may use scoped direct operations. A live patch to an Argo-managed resource can be undone by self-healing reconciliation https://argo-cd.readthedocs.io/en/stable/user-guide/auto sync/ , so each resource needs a clear owner. These controls should be part of the environment profile and tested like product behaviour. Test that one agent cannot read another experiment's Secrets, select an administrative service account, extend its own lease indefinitely or target production. A successful “permission denied” is a useful platform test result. The experiment ends when the resources are gone There is a trap hidden in almost every ephemeral-environment demo: the happy path deletes the namespace, then the presenter closes the laptop. Kubernetes' ttlSecondsAfterFinished https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/ cleans up finished Jobs. It does not expire a namespace, delete a Cluster API cluster or close the bill for a cloud database. Every environment needs a platform-owned lease, an enforced maximum duration and cleanup independent of the agent that created it. Make teardown an ordered workflow. Mark the environment as retiring and stop new work. Export the evidence. Remove application desired state and wait for workload and cloud-resource cleanup while the cluster and its deployment credentials remain available. Only then retire the cluster’s desired state, let Cluster API complete deletion, and remove cluster registration and access. Ensure neither GitOps nor the request controller can recreate retired resources. Inspect failures and finalizers; do not blindly strip the mechanisms that track outstanding deletion. The order has real consequences. The CAPI cleanup instructions https://cluster-api.sigs.k8s.io/user/quick-start clean-up recommend deleting the Cluster object rather than all generated resources together. AWS's EKS deletion instructions https://docs.aws.amazon.com/eks/latest/userguide/delete-cluster.html call for removing relevant Services and Ingresses before deleting the cluster to avoid leaving load balancers. Kubernetes volumes with a Retain policy https://kubernetes.io/docs/concepts/storage/persistent-volumes/ reclaiming can outlive their claims. Closing a pull request can remove an ApplicationSet-generated Application, but actual resource removal depends on finalizers and preservation settings https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Application-Deletion/ . It is not a universal instruction to delete the underlying cluster. Give cluster lifecycle ownership to the platform and verify the billable inventory afterwards. The most revealing acceptance test is simple: kill the agent halfway through provisioning. The platform must still know what was requested, what exists, who owns it, when it expires and how to remove it. Repeat the exercise with a failed workflow and a temporarily unavailable provider. That is how “ephemeral” becomes an operational property. Make parallelism affordable Consider an illustrative workload, not a benchmark: five candidates per hour, each occupying an environment for twenty minutes, require about 1.7 concurrent environments on average. Fifty candidates per hour require about 16.7. Bursts, setup time, retries and longer tests push the required capacity higher. Sending ten times as much work into the original capacity produces a queue, however intelligent the developer's assistant may be. Start cheap checks early and reserve expensive environments for the questions they answer. Reuse immutable build artefacts and caches with appropriate trust boundaries. Use namespaces for ordinary previews, reserve full clusters for infrastructure fidelity, and maintain small warm pools only where reduced waiting justifies their idle cost. Scale worker capacity with admitted demand; include the provisioning delay in the promised feedback time. ResourceQuota https://kubernetes.io/docs/concepts/policy/resource-quotas/ constrains namespace consumption and object counts. It is not a cloud spending limit. Combine it with allowed instance sizes, maximum cluster counts, lifetime limits, storage limits, tool-call and token budgets, and a platform admission decision before work starts. Billing observation is useful, but a delayed cost report cannot prevent every overspend. When verification becomes a substantial shared batch service, Kueue https://kueue.sigs.k8s.io/docs/overview/ is worth evaluating for workload admission against available quota. Its role is to decide which work may run; it does not by itself create the cloud capacity. A small team can begin with its existing CI queue and a global concurrency cap. Measure time to trustworthy evidence, accepted changes per day, escaped defects, flaky-test rate, cost per accepted change, repeated failed attempts and orphaned resources. A platform that produces twice as many rejected changes for ten times the compute has not delivered the transformation. The advantage comes from spending parallel compute on questions that improve the product. The frontier is already taking shape Two upstream developments make this more interesting than a collection of scripts. SIG Apps' Agent Sandbox https://github.com/kubernetes-sigs/agent-sandbox supplies a Kubernetes API for stateful agent execution environments, with extensions for templates, claims and warm pools. It orchestrates sandboxes; low-level isolation comes from the configured runtime, such as gVisor or Kata Containers. This offers a purpose-built place for agents to execute and retain working state while the platform controls their lifecycle. SIG Network's Kubernetes Agentic Networking https://kube-agentic-networking.sigs.k8s.io/introduction/ is developing APIs for agent-to-tool communication and MCP tool authorisation. Its documentation describes an evolving prototype and alpha APIs, so it belongs on an evaluation track. The direction matters: the network can understand which agent is allowed to call which tool, while application services still validate the particular action and its arguments. At the runtime layer, kagent https://kagent.dev/ is one option for defining and running agents as Kubernetes resources with MCP integrations. It is optional. Your existing agent runner can use the same platform API. The infrastructure contract should survive a change of model, coding assistant or orchestration framework. Put those developments together and a plausible future emerges: agents are identifiable platform users, workspaces are disposable resources, verification is a schedulable workload, and every significant action has a budget and a record. The machinery of a software organisation starts to become programmable. A small team with a very large capability Start by giving one team read-only diagnostics and a single dependable preview profile. Make the first end-to-end path produce evidence and prove cleanup after failure. Then automate independent QA runs, introduce full-cluster profiles where their fidelity matters, and add scheduled upgrade and recovery experiments. Expand authority as the platform demonstrates that it can contain and explain its actions. Now return to Monday, at 18:05. In the version of this story worth building, Maya is reviewing a migration failure with a precise reproduction. Another developer is comparing two implementation approaches against the same workload. Overnight jobs will test supported platform versions and rehearse a database restore. Unused environments are disappearing. Nobody has filed a ticket asking another team to make staging usable. The platform team has built a service through which everyone can ask difficult questions of working software. QA has encoded the behaviours that must remain true. Developers spend more of their attention deciding what to build and judging the results. Agents supply parallel implementation, investigation and experimentation around those human decisions. That is how a few people could aim for the delivery capacity that once needed several hundred: by automating much of the coordination, environment preparation, testing and operational investigation that surrounded every change. It is an ambitious operating model, not a measured headcount equivalence. Product judgment, accountability and customer understanding remain essential, and the result must be judged by value delivered. Kubernetes gives this ambition somewhere concrete to run. Cluster API can supply the clusters. Argo CD can deliver the desired applications. MCP can make the platform accessible to an agent. The platform team's contribution is to connect those parts into a system that can turn an idea into an experiment, an experiment into evidence, and unused infrastructure back into available capacity. A small team should be able to ask a hundred serious questions of its software before lunch, then spend the afternoon acting on the answers. Research checked on 9 October 2026. This is a proposed architecture based on upstream documentation and inspected implementations, not a KubeDEX production deployment or hands-on benchmark. The team, timeline and capacity example are illustrative. Tool versions and experimental features are identified where they materially affect the design. Sources & further reading Spotted something that needs another look? Help improve this page → https://kubedex.com/contact/