Kubernetes API Resources
What does zop.dev create for Kubernetes API Resources?
zop.dev bridges into any reachable cluster and manages 11 Kubernetes resource kinds directly: configmap, cronjob, deployment, hpa, job, namespace, node, pdb, pod, secret, and service. Cluster credentials can be supplied as a kubeconfig, a host with certificates, a bearer token, or a username and password.
| Field | Value |
|---|---|
| Cloud | cross-provider |
Sometimes you need to manage raw Kubernetes objects, not just zop.dev’s higher-level abstractions. zop.dev bridges into any reachable cluster and manages core API objects directly.
Eleven core Kubernetes object kinds
Eleven Kubernetes resource kinds: configmap, cronjob, deployment, hpa, job, namespace, node, pdb, pod, secret, and service.
Cluster credentials in several shapes
Cluster credentials accepted in multiple shapes: kubeconfig path or content, host with CA and client cert/key, bearer token, username/password, context, namespace, and insecure flag.The GKE cluster resource fetches the kubeconfig
Reached through the GCP gke resource type, which fetches the cluster’s kubeconfig and acts on the object kind named in k8s_resource_type.
The escape hatch below the abstractions
Most of the platform speaks in higher-level nouns: services, namespaces, datastores. This is the layer beneath: 11 core API object kinds, for the cases the abstractions do not cover. Patching a configmap the platform did not author, draining decisions that need node objects, one-off jobs, inspecting a pod directly. The value is reach; the discipline is using it for what genuinely has no higher-level expression, because objects managed here live outside the specs the platform reconciles.
Reached through the gke bridge
The path in is indirect by design: the GCP gke bridge resource type fetches the cluster’s
kubeconfig and acts on the object kind named in k8s_resource_type. One API flow
covers “find the cluster, authenticate, act on an object inside it”, which is also why the
credential input is so flexible. Kubeconfig by path or content, host with CA and client
certificate and key, bearer token, username and password, plus context, namespace, and an
insecure flag. That flexibility exists for reachability across cluster generations; the
insecure flag in particular is a debugging tool, not a configuration.
Edits that Helm will fight
The sharp edge of raw object access: anything under a Helm release’s management is owned by that release. Hand-edit a deployment that a release renders, and the change holds only until the next upgrade re-renders it, leaving drift that looks like a mystery regression weeks later. The safe uses are objects nothing else owns, or reads. For owned objects, change the release’s values instead, so the source of truth stays where the platform expects it. Secrets deserve one extra caution: they are among the 11 kinds, and access to this layer is access to every secret in reach of the credential supplied.