---
name: kubernetes-platform-operations
description: Inspect, diagnose, deploy, and safely operate Kubernetes and OpenShift workloads, namespaces, deployments, stateful sets, services, ingresses, jobs, secrets metadata, RBAC, network policies, storage, autoscaling, rollouts, Helm releases, events, logs, and cluster capacity. Use with the official containers/kubernetes-mcp-server or kubectl-compatible tooling when a project moves beyond Coolify or requires orchestration.
compatibility: Begin with namespace-scoped read-only credentials. Apply, rollout, scale, exec, secret, RBAC, storage, node, cluster-wide, and deletion operations require separate authorization and narrowly scoped service accounts.
license: Apache-2.0
---

# Kubernetes platform operations

Kubernetes availability depends on desired objects, controllers, scheduling, networking, storage and application health. A running Pod is not sufficient proof of service health.

## Diagnostic workflow

1. Identify cluster, context, namespace, workload, release and user-facing symptom.
2. Read workload status, conditions, events, rollout history, Pods and controller ownership.
3. Inspect requests, limits, scheduling constraints, probes, configuration references and storage claims.
4. Trace service, endpoints, ingress or gateway, DNS and network policy.
5. Review bounded logs and metrics for representative Pods.
6. Compare current state with the deployed manifest or Helm release.
7. Form a minimal reversible remediation.
8. Verify rollout, endpoints, probes, application requests and error telemetry.

## Change workflow

Use declarative manifests, Helm values or GitOps sources rather than one-off imperative changes. Produce a server-side dry run and diff where supported. Never apply an unreviewed generated manifest directly to production.

## Permission separation

Use independent service accounts or deployments for:

- namespace read;
- workload deployment and rollout;
- scaling;
- logs and exec;
- secret management;
- RBAC and network policy;
- storage;
- node and cluster administration;
- destructive actions.

The persistent MCP router should normally receive only namespace-scoped read access.

## Safety rules

- Do not expose Secret data, service-account tokens or kubeconfig content.
- Do not delete Pods repeatedly without diagnosing their controller and failure cause.
- Do not force-delete stateful workloads or PVCs without storage and recovery evidence.
- Do not broaden RBAC or network policy merely to make a deployment work.
- Check disruption budgets, readiness gates and capacity before rollouts or drains.
- Use exact cluster and namespace identifiers in every report.

## MCP deployment

Deploy the official Kubernetes MCP in-cluster or on a controlled administration host. Restrict its service account, network policy and accessible contexts. Register it in compact read-only mode and classify mutation tools before enabling any operations deployment.

## Output

Return cluster and namespace, affected resources, observed conditions and events, manifest drift, root-cause confidence, proposed change, dry-run or diff, capability gate, rollout verification, rollback and remaining platform risk.