Concepts overview

Core Kubernetes objects and the practical meaning they have inside the portal: what they represent, when to inspect them and how they relate to each other.

PodsWorkloadsNamespacesNodes
Docs homeConceptsPlatform structureOperator guideTroubleshootingSecurityReference

Pods and containers

A pod groups one or more containers that share network and, optionally, storage. Operators usually inspect pods for readiness, restart growth, image version, placement and recent warnings.

Service discovery flow inside a Kubernetes cluster
Service discovery is a useful mental model: a service gives workloads a stable cluster-facing entry point while pods behind it can change over time.Service discovery diagram

Compute

Pods, deployments, daemon sets, stateful sets, jobs and cron jobs describe how work is placed and updated.

Access and policy

Roles, bindings, service accounts, network policy and secrets define boundaries around that work.

Routing and storage

Services, ingress, persistent volumes and claims explain how workloads receive traffic and keep state.

ExampleA healthy pod can still deserve attention if restarts are growing, a warning event references image pull failures, or the owning workload is only partially ready.

Workload controllers

  • Deployment — manages stateless replicas and rolling updates.
  • StatefulSet — keeps stable identities and ordered rollout for stateful services.
  • DaemonSet — places one pod per node for agents such as logging, security or telemetry.
  • Job/CronJob — runs finite or scheduled work outside the steady-state service path.

Services and ingress

Services provide stable cluster-facing addresses in front of dynamic pod endpoints. Ingress resources describe HTTP(S) routes and termination boundaries.

NoteWhen a workload looks healthy but user traffic still fails, compare service and ingress details with recent warning events before assuming the pods are the problem.

Namespaces and policy

Namespaces provide boundaries for ownership, policy, quotas and access. They are often the fastest way to interpret related events because most warnings, workloads and configuration objects cluster around a namespace boundary.

  • Use namespace details to identify owner, related workloads and recent activity.
  • Review network policy and service account patterns together when access looks inconsistent.

Reading the portal

The portal surfaces these objects as summary cards, searchable tables and detail drawers. A good reading order is usually:

  1. open the affected object,
  2. check status, age, owner and recent activity,
  3. follow links to related node, namespace, event or image metadata,
  4. switch to observability when repeated warnings need more context.
GlossaryOperator guideRelated objects guide
← Documentation centerPlatform structure →