Kubernetes management across every cluster you run
One inventory, one deployment path and one security posture across EKS, AKS, GKE, OpenShift and self-managed clusters, without a different console for each provider.
What is Kubernetes?
DevOpsArk Kubernetes management is the module that gives engineering teams a single control plane for operating multiple Kubernetes clusters (inventory, workload deployment, monitoring, cost attribution and security posture) across cloud providers and on-premises environments.
What Kubernetes is for
The conditions this module removes. If none of these are familiar, you probably do not need it yet.
- Each cloud provider ships its own Kubernetes console, so operating three providers means learning three consoles and reconciling three answers.
- Cluster inventory is a mystery. Nobody is certain how many clusters exist, what versions they run or which are still in use.
- A Kubernetes version upgrade means auditing every workload for removed APIs, by hand, per cluster.
- Resource requests were copied from a tutorial in 2022 and have never been revisited, so half the fleet is over-provisioned and the other half is throttled.
- RBAC accumulates. Nobody can answer who can delete a production namespace.
DevOpsArk connects to each cluster through its Kubernetes API using scoped credentials and builds a live inventory of clusters, nodes, namespaces, workloads and their relationships. From that single index it drives the operations that normally require a per-provider console: deploying workloads through ArkCD, collecting metrics and logs, attributing cost to namespaces and teams, checking configuration against security policy, and detecting deprecated API usage ahead of a version upgrade. Because the inventory spans every cluster, questions that were previously per-cluster become one query: "which namespaces run privileged containers", "which clusters are two versions behind", "what does the payments team cost across all environments". Ark agents work against the same index, so an analysis of a failing workload can reference the cluster, the recent deployment and the log stream together.
What Kubernetes does
The 9 capabilities that make up Kubernetes.
Multi-cluster inventory
Every cluster, node pool, namespace and workload across EKS, AKS, GKE, OpenShift and self-managed Kubernetes in one index.
Workload deployment
Deploy and promote workloads across clusters through ArkCD, with per-cluster strategy, configuration and approvals.
Cluster and workload monitoring
Node pressure, pod restarts, scheduling failures, resource saturation and control-plane health, with history rather than a live-only view.
Security posture
Privileged containers, host mounts, missing network policies, over-broad RBAC and unpatched node images, checked continuously against policy.
Cost attribution
Cost broken down by cluster, namespace, workload and team, including the share of idle capacity each is responsible for.
Right-sizing recommendations
Requests and limits compared against observed usage, with a concrete recommended value and the saving it produces.
Deprecated API detection
Workloads using APIs removed in the next Kubernetes version are listed per cluster before the upgrade, not during it.
Namespace and RBAC review
Answer who can do what in which namespace, and find the role bindings that grew wider than anyone intended.
Agent-led diagnosis
Ark correlates pod events, container logs, resource pressure and recent deployments to explain why a workload is unhealthy.
How Kubernetes fits together
Outcomes
- One console replaces one console per provider, and the answers reconcile because they come from one index.
- Version upgrades are planned from a deprecated-API list rather than discovered during the upgrade.
- Over-provisioning is visible per workload with a specific recommended value, so right-sizing is a decision rather than a project.
- Security posture is continuous, so a privileged container is caught the day it is deployed.
- Cost is attributable to a team, which makes the conversation about it possible.
Using Kubernetes, step by step
The path from connecting a source to getting value, in the order it happens.
- 1Connect the cluster
Register the cluster with scoped credentials; read-only is enough to start.
- 2Build the inventory
Nodes, namespaces, workloads and their relationships are indexed continuously.
- 3Apply the baseline
Security and configuration policy is evaluated against every cluster.
- 4Deploy through one path
Workloads are released and promoted via ArkCD with per-cluster rules.
- 5Operate and optimise
Monitor health, attribute cost, act on right-sizing, and plan upgrades from the deprecated-API list.
Where teams apply Kubernetes
Operate a multi-cloud Kubernetes fleet
Manage EKS, AKS and GKE clusters from one plane with a shared deployment path and a shared security baseline.
Plan a Kubernetes version upgrade
Get the list of workloads using APIs that the target version removes, per cluster, before the upgrade window.
Attribute Kubernetes spend
Break cluster cost down to namespace and team, including idle capacity, and act on right-sizing recommendations.
Enforce a cluster baseline
Continuously check every cluster for privileged workloads, missing network policies and over-broad RBAC.
What Kubernetes works with
Named integrations link to their own page. The rest are supported runtimes and formats.
Kubernetes: frequently asked questions
The 12 questions teams ask most often before adopting Kubernetes.
A Kubernetes management platform is a control plane that operates multiple Kubernetes clusters from one place (inventory, workload deployment, monitoring, cost, access control and security posture) instead of using each provider console separately.
Yes. Multi-cluster is the default assumption. Clusters across different providers, regions and environments appear in one inventory, and policy, deployment and cost views span all of them.
Amazon EKS, Azure AKS, Google GKE, Red Hat OpenShift, Rancher-managed clusters and self-managed upstream Kubernetes, on cloud or on-premises.
No. DevOpsArk connects through the Kubernetes API and can operate entirely agentlessly, which is what most teams start with. An optional in-cluster component is available where you want higher-frequency metrics collection.
Yes, through ArkCD. Workloads are reconciled against declared desired state, rolled out progressively with metric gates, and rolled back automatically if release health degrades.
Yes. It collects cluster and workload metrics, pod events and container logs, tracks node pressure, restart loops and scheduling failures, and retains history so you can look at what happened rather than only at what is happening.
Cost is attributed to cluster, namespace, workload and team, including each one share of idle node capacity. Right-sizing recommendations compare configured requests against observed usage and state the saving from each change.
Before an upgrade it lists every workload in every cluster that uses an API the target version removes, along with the manifest location to change. After the upgrade it verifies that node pools, add-ons and workloads reconciled successfully.
Yes. Any cluster reachable by its Kubernetes API can be managed, including air-gapped and on-premises clusters connected through an outbound relay.
A provider console manages that provider clusters only. DevOpsArk spans providers, adds the deployment, cost, security and agent layers on top of the inventory, and gives one answer to a question that would otherwise be asked separately in each console.
A read-only ClusterRole is enough for inventory, monitoring, cost and security posture. Deployment and remediation require scoped write permissions, which you grant per cluster and per namespace.
It reviews RBAC (showing which subjects can perform which verbs in which namespaces, and highlighting bindings wider than the baseline), and can apply changes where you have granted write scope.
See Kubernetes against your own environment
A 30-minute walkthrough with a platform engineer, not a sales deck. Bring a cluster and a problem.