Platform structure

A high-level map of where control plane services, workload traffic, stateful components and access boundaries fit together. The goal is operator orientation, not implementation trivia.

Control planeTrafficStateful services

Control plane path

The API server remains the control-plane entry point for desired state. Controllers reconcile drift, the scheduler places pods and etcd preserves cluster metadata. The portal mirrors this vocabulary so operators can move between UI labels and normal Kubernetes troubleshooting without translation.

Traffic and exposure

  • Pod-to-pod communication is handled by the cluster networking layer.
  • Services provide stable east-west addresses.
  • Ingress resources define north-south HTTP(S) routes and TLS termination points.
WarningIf ingress appears healthy while upstream checks still fail, inspect service endpoints and recent events before escalating to certificate or DNS owners.

Stateful services

Stateful services such as databases, queues and metrics stores rely on persistent volumes, predictable identity and ordered rollout behavior. Review stateful workloads together with node placement, storage class expectations and restart patterns.

Access boundaries

The portal provides read-only operational visibility. Object inspection, health review and relationship tracing happen here; mutating actions stay on the standard administration path.

AreaTypical useFollow-up path
PortalStatus review, event reading, image lookupContinue to admin tooling for write actions
ObservabilityRelated signals, warning streams, event interpretationUse object links to return to affected workload or namespace
RegistryImage version, digest and ownership reviewUse rollout or delivery tooling for promotion