DMK8S: managed Kubernetes, operated by the platform that watches it
Provision a production-shaped cluster in minutes with patching, upgrades, backups, monitoring and security baseline already attached, not as five follow-up projects.
What is DMK8S?
DMK8S is the DevOpsArk managed Kubernetes service that provisions, patches, upgrades and operates production-ready clusters with the DevOpsArk delivery, observability and security modules attached from the moment the cluster exists.
What DMK8S is for
The conditions this module removes. If none of these are familiar, you probably do not need it yet.
- A managed control plane still leaves you to build ingress, storage classes, monitoring, log shipping, policy and backups before anyone can deploy.
- Cluster upgrades are deferred because nobody has time to plan them, so the fleet falls behind supported versions.
- Every team builds its own cluster shape, so no two clusters in the organisation behave alike.
- Node patching happens when someone remembers.
- The observability stack is a separate project that starts after the cluster is already in use.
DMK8S provisions a cluster from a curated shape: node pools sized for the workload class you selected, an ingress controller, storage classes, network policy defaults, log and metric collection, a security baseline and a backup schedule. Control plane and node patching run on a managed cadence with a maintenance window you set. Minor-version upgrades are planned against a deprecated-API report drawn from the workloads actually running, so the upgrade proposal arrives with its own impact list. Because the cluster is created inside DevOpsArk, ArkCD, monitoring, vulnerability management and cost attribution are attached from the first minute rather than retrofitted. The cluster runs in your cloud account, so the workloads and data stay where your policy requires.
What DMK8S does
The 7 capabilities that make up DMK8S.
Curated cluster shapes
Provision from a reviewed template (node pools, ingress, storage classes, network policy and add-ons) instead of assembling it per team.
Managed patching and upgrades
Node images and control plane are patched on a cadence inside your maintenance window, with upgrades planned against a real impact list.
Backup and restore
Scheduled cluster-state and persistent-volume backups with tested restore, configured at provisioning rather than later.
Security baseline from day one
Pod security standards, network policy defaults, image policy and RBAC baseline applied at creation.
Observability attached
Metric and log collection, dashboards and alert routing exist before the first workload is deployed.
Cost visibility from the start
Namespace-level cost attribution is on from the first day, so spend never becomes retrospective archaeology.
Runs in your cloud account
Clusters are provisioned into your AWS, Azure or Google Cloud account, so data residency and network policy stay yours.
How DMK8S fits together
Outcomes
- A team gets a production-shaped cluster the same day rather than after a platform project.
- Clusters stay on supported versions because upgrades are planned, not deferred.
- Every cluster in the organisation behaves the same way, which makes incidents transferable.
- Observability, backup and security exist before the first workload, not after the first incident.
- Workloads and data remain in your own cloud account.
Using DMK8S, step by step
The path from connecting a source to getting value, in the order it happens.
- 1Choose a shape
Select the workload class, region and size; the template supplies the rest.
- 2Provision
The cluster is created in your cloud account with add-ons, policy and collection configured.
- 3Deploy
ArkCD is already connected, so the first workload ships immediately.
- 4Operate
Patching, backups, monitoring and cost attribution run continuously.
- 5Upgrade on cadence
Upgrade proposals arrive with a deprecated-API impact list drawn from your running workloads.
Where teams apply DMK8S
Give teams clusters without growing the platform team
Self-service provisioning from a reviewed shape, operated centrally.
Standardise the fleet
Replace bespoke per-team clusters with one shape that upgrades and patches on a known cadence.
Stop deferring version upgrades
Take upgrade proposals that already carry their deprecated-API impact list.
Run Kubernetes without a Kubernetes team
Get the operational layer as a service while keeping the cluster in your own account.
What DMK8S works with
Named integrations link to their own page. The rest are supported runtimes and formats.
DMK8S: frequently asked questions
The 8 questions teams ask most often before adopting DMK8S.
DMK8S is the DevOpsArk managed Kubernetes service. It provisions production-shaped clusters into your own cloud account and operates them (patching, upgrades, backups, monitoring and security baseline) with the DevOpsArk delivery and observability modules attached from creation.
Those services manage the control plane. DMK8S manages the whole operational layer on top of it: ingress, storage classes, policy baseline, log and metric collection, backups, cost attribution and the delivery path. It can run on top of EKS, AKS or GKE rather than replacing them.
In your own AWS, Azure or Google Cloud account. Workloads and data stay under your cloud governance and data-residency rules.
Patch-level updates run on a managed cadence inside a maintenance window you set. Minor-version upgrades are proposed with an impact report listing the workloads in that cluster using APIs the target version removes.
DevOpsArk operates the cluster through scoped Kubernetes and cloud credentials. It reads cluster state, events and metrics; application data in your persistent volumes is not read as part of managing the cluster.
Yes. The cluster is a standard Kubernetes cluster in your own account. If you stop using DMK8S, the cluster and its workloads remain and management reverts to you.
Yes. Cluster state and persistent volumes are backed up on a schedule set at provisioning, with restore tested as part of the service rather than assumed.
Yes. Shapes are templates, not fixed products: node pools, add-ons, policy defaults and network configuration can be adjusted, and your adjustments become a shape your other teams can provision from.
See DMK8S against your own environment
A 30-minute walkthrough with a platform engineer, not a sales deck. Bring a cluster and a problem.