Open navigation

Daily Kubernetes Operations

This page explains how users typically work with a provisioned cluster in the web console, including status checks, inspection flows, troubleshooting entry points, and deletion.

Daily Kubernetes Operations

This page explains how users typically work with a provisioned cluster in the web console, including status checks, inspection flows, troubleshooting entry points, and deletion.

What the list page is for

The Kubernetes list page is useful for three routine tasks:

  • Checking whether clusters look healthy.
  • Opening a specific cluster.
  • Selecting and deleting clusters that are no longer needed.

Which columns to review first

  • Name: the main entry to cluster details.
  • Status: whether the cluster is running, creating, failed, or deleting.
  • Version: whether the platform version matches expectation.
  • Control-plane and worker-node counts: whether the size looks correct.
  • Health: whether there is a broad node-health issue.

What to check first after opening a cluster

Overview page

Use it to confirm:

  • Whether the cluster is available.
  • Whether the node count is complete.
  • Whether the pod total looks abnormal.
  • Whether aggregate CPU, memory, or storage usage is already high.

Nodes page

Use it to investigate:

  • Whether any node is not ready.
  • Whether a node role is missing or undersized.
  • Whether resource pressure is high on a subset of nodes.

If the product exposes actions such as cordon and uncordon, this is also where you would use them during maintenance.

Workloads page

This page is the main place to inspect:

  • Deployments.
  • StatefulSets.
  • DaemonSets.
  • Jobs and CronJobs.
  • Pod instance state.

When an application is unhealthy, start from the workload view before moving back to nodes or networking.

Network page

This area typically shows:

  • Services.
  • Gateway resources.
  • Network policies.

If a service is unreachable from outside, check in this order:

  1. Whether the Service is exposed correctly.
  2. Whether the Gateway exists.
  3. Whether the gateway network is correct.
  4. Whether the security group allows the required ports.

Storage page

Use it to verify:

  • Whether PVCs are bound.
  • Whether the storage class matches workload expectations.

This is especially important for databases and other stateful applications.

Configuration and access pages

These pages are commonly used to inspect:

  • Namespaces.
  • ConfigMaps.
  • Secrets.
  • ServiceAccounts.
  • Roles and bindings.

If application configuration is missing or access control looks wrong, start here.

Refresh and confirm recent changes

After creation, configuration changes, or deletion, the list page may not update immediately. A good sequence is:

  1. Click Refresh on the list page.
  2. Recheck the current status.
  3. If the state still looks wrong, continue with the order record, notifications, and the cluster detail pages.

Delete a cluster

  1. Return to the Kubernetes list page.
  2. Select the target cluster or clusters.
  3. Click Delete.
  4. Confirm the action in the dialog.

After that, the cluster usually enters Deleting status and may remain visible in the list until the workflow finishes.

Common troubleshooting order

The cluster exists but the application is unavailable

Check in this order:

  1. Whether all nodes are ready.
  2. Whether workloads started correctly.
  3. Whether Service and gateway exposure are correct.
  4. Whether security-group and external-network rules allow access.

Node health is dropping

Start from the Nodes page, then return to Overview to decide whether it is a single-node issue or a broader capacity problem.

External access is failing

Check gateway settings, security-group rules, and service exposure before assuming the application itself is broken.