Open this resource#

Console route: /pods. This is a namespaced resource; choose the namespace before making a change.

  1. Select the correct cluster in the sidebar.
  2. Open Pods and narrow the list using the available namespace/search controls.
  3. Select the exact object by name. Verify its scope and identity at the top of the detail page.
The pod list exposes readiness, restarts and node placement. Select the correct namespace before opening a pod.
The pod list exposes readiness, restarts and node placement. Select the correct namespace before opening a pod. View full size ↗

What to inspect#

Containers, readiness, restarts, node placement, volumes and events.

Refresh the resource when you need the latest observation. Overview fields summarize the object; YAML exposes the complete returned document. A placeholder or missing status field should not be read as a successful or zero-valued result.

Use the available features#

Open Containers to inspect the image and resource settings. Use Logs, Terminal and Files for the selected container. Volumes and Related show the surrounding context. Monitor depends on metrics availability. The Resize Resources action is exposed only when the reported cluster version is at least 1.35.0, containers exist and update access is allowed; the backend/cluster must still accept the resize.

Describe, Clone, YAML editing and Delete are shared resource actions where the page and your permissions allow them. Read Create, edit, clone and delete resources before applying a change.

A practical investigation#

For a restarting pod, select the failing container, read its Previous Container logs and compare the last failure with Events. If a controller owns the pod, fix its pod template rather than expecting a direct pod edit to persist.

  1. Establish the current state and the symptom you want to resolve.
  2. Identify whether a controller, Helm release or Delivery project owns the object.
  3. Make the smallest authorized change through that owner when possible.
  4. Refresh and verify the resulting resource state. Inspect related objects rather than stopping at a successful save message.

Permissions and unavailable data#

Listing this kind does not automatically grant every subresource action. The console checks operation access, and Kubernetes still checks the connected identity. If this API is not served by the cluster, fix the installation/version capability rather than treating an empty or unavailable page as an authorization grant.