Kubernetes Clusters

Talos Director runs Kubernetes workload clusters directly on the virtualization substrate. Because Kubernetes spans more than one VM — it depends on IP pools, zones, versions, providers, and management-cluster state — the Kubernetes section keeps those dependencies explicit and manages the full cluster lifecycle in one place. This page covers the three screens you’ll use most: the fleet-level Kubernetes dashboard, the Kubernetes Clusters inventory, and the cluster detail screen.

​

The Kubernetes dashboard

Navigate to Kubernetes (/kubernetes) for a fleet-level overview of every managed cluster. Use it to answer “is the fleet healthy, and where should I look next?” before opening any individual cluster. The dashboard presents:

• Fleet summary tiles — total clusters with ready/failed counts, total nodes with how many are ready, healthy clusters with degraded and unhealthy counts, and whether the Kubernetes management service is online.
• Upgrades in Progress — any cluster upgrades currently running, so rolling operations are never invisible.
• Needs Attention — a triage list of clusters that are degraded, unhealthy, or failed, with the reason (for example, etcd quorum unhealthy). Each entry links to the affected cluster.
• Cluster table — recent clusters with status, version, node readiness, health, and age.

Two controls sit above the dashboard: Refresh reloads fleet state, and Create Cluster starts the cluster creation workflow.

​

The Kubernetes Clusters view

Navigate to Kubernetes > Clusters (/kubernetes/clusters) for the full cluster inventory.

​

Columns

The table shows the following columns.

​

Controls

The controls above the table let you search, shape, and export the view:

• Filter clusters… — narrow the table with free text or query-style expressions, for example status:ready.
• Columns — choose which columns are visible.
• Export CSV — download the current view for reporting or offline analysis.
• Refresh — reload cluster data on demand.
• Create Cluster — provision a new workload cluster.
• Global search — the top-bar search spans VMs, hosts, networks, and users, and supports scoped queries such as vm:name.

​

Create a cluster

Select the + Create Cluster button to provision a new Kubernetes cluster. The workflow has the following stages, followed by a final review.

​

Cluster details

Name the cluster and choose the operating system and Kubernetes versions.

​

Infrastructure

Choose where the cluster’s nodes run.

​

Networking

Configure how the cluster’s nodes, pods, and services are addressed.

​

Node configuration

Size the control plane and define the worker node pools.

Control plane nodes

Control-plane nodes run the Kubernetes API server and etcd.

Worker node pools

Worker nodes run your workloads, grouped into pools.

​

Add-ons

Select the add-ons to install with the cluster. You can also install add-ons later from the cluster’s Add-ons tab.

​

Cluster settings

Set backup, protection, and registry behavior for the cluster.

​

Review and create

Review the configuration of the Kubernetes cluster — select Back to return to a previous step if you need to adjust the configuration. Select Create Cluster to complete the setup.

​

The cluster detail screen

Click a cluster name to open its detail screen. The header shows the cluster’s status, Kubernetes version, and node OS version, plus two primary actions:

• Kubeconfig — download the kubeconfig for CLI and CI access to the cluster.
• Upgrade — start a guided cluster upgrade.

A kubectl Console is also available from the detail screen, keeping command-line access one click away without leaving the browser. The tabs below the header cover the cluster’s complete operational surface.

​

Overview

The landing tab summarizes cluster configuration: API endpoint, Kubernetes and OS versions, pod CIDR, service CIDR, CNI (for example, Flannel), load balancer (for example, MetalLB), the zones the cluster spans, control-plane anti-affinity state, preferred host, and creation time.

​

Configuration

Controls where the cluster’s control plane runs and which container registry mirrors its nodes pull through. Node pools are placed independently from each pool’s own settings. Saving a preferred host migrates the control-plane VMs that are not yet on it one at a time; setting the preference back to Any moves nothing and leaves future placement to the scheduler.

​

Nodes

Per-node inventory headed by a health summary (nodes ready, cordoned, pressured, locked). Each row shows the node’s health, role (control plane or worker), pool, Kubernetes and OS versions, IP address, the hypervisor host running it, age, CPU and memory resources with live utilization, pod count against capacity, and heartbeat freshness. Row actions cover node-level operations.

​

Node Pools

Declarative groups of worker nodes. Each pool shows its status, node count against its minimum and maximum, per-node instance resources (CPU, memory, disk), and whether autoscaling is enabled. Click Add Node Pool to create one; scale a cluster by editing a pool rather than managing individual nodes.

​

Autoscaler

Live autoscaling state per pool: current node count against min/max bounds, the scaling method (for example, pod requests utilization), and the signals driving decisions — average CPU against the scale-up and scale-down thresholds, average memory, and pod count against schedulable capacity — plus when the pool last scaled.

​

Backups

Scheduled and on-demand cluster backups, headed by a Backup Health indicator showing time since the last success. Each backup lists its status, size, type (scheduled or manual), creation time, expiration, and restore history. Click Create Backup for an on-demand backup.

​

Monitoring

Component-level System Health across the cluster’s moving parts: certificates, CNI, control plane, CoreDNS, etcd, etcd backup freshness, kube-proxy, the Kubernetes API, metrics server, node conditions, pod scheduling, and workers. Use this tab to turn a Degraded verdict into a specific failing component.

​

Storage

Persistent storage for the cluster through CSI integration. If no CSI add-on is installed, this tab reports Storage Not Configured and directs you to the Add-ons tab to install one.

​

Add-ons

The installed add-on inventory and a catalog of curated add-ons (for example, Metrics Server for the resource metrics API, or Spegel for peer-to-peer image distribution). Each add-on shows its category, version, status, health, and install time. Click Install Add-on to add from the catalog.

​

Upgrade health checks

The guardrails that protect cluster upgrades. Built-in checks always apply, with no configuration required:

• All nodes must be Ready before an upgrade starts.
• Nodes are replaced one at a time — the replacement node must join and become Ready before the old node is drained and removed.
• Control-plane rollouts are gated so the control plane stays available throughout.

​

Security

Security posture in one place, organized into Policies, Findings, Runtime, Compliance, Risk, Namespace Security, and Control Plane PSA views. Admission policy management requires the policy engine add-on (Kyverno); if it is not installed, this tab directs you to the Add-ons tab.

​

Diagnostics

On-demand health checks. Click Run All Checks to execute predefined diagnostics across nodes, DNS, networking, etcd, storage, and more — a faster first step than assembling the same picture manually with kubectl.

​

Events

The cluster’s operational history, filterable by severity (Info, Warning, Error, Critical), type (Provisioning, Error, Scaling, Health, Lifecycle, Configuration), source (Controller, API, Autoscaler, User), and time range. Use it to reconstruct what happened and who or what triggered it.