Platforms

Platforms: OpenShift, OLM, vcluster, k3s and RKE2

Sextant recognises a few Kubernetes platforms and adds their own objects to the sidebar. Each section appears only when the cluster serves its kinds, and everything is read-only except the actions named below, which always ask first.

OpenShift

On clusters that serve OpenShift's APIs an OpenShift section lists Routes, DeploymentConfigs, BuildConfigs, Builds, ImageStreams and Projects.

• Routes say whether a router admitted them, where they answer, how TLS ends and how requests split across Services and their ready pods. The certificate fields show only as "set"; the private key is never shown in the Route views. Diagnose follows a Route to its pods the way it does for an Ingress (see Traffic diagnosis).
• DeploymentConfigs show their rollout state, triggers and ReplicationControllers. Rollout latest sends exactly what oc rollout latest sends, after a confirmation that shows the request.
• BuildConfigs and Builds show why a build failed and open the build pod's logs. Start build sends what oc start-build sends, after a confirmation. Webhook secrets are never read.
• ImageStreams list their tags and import errors. Projects show their display name, description and requester.
• Routes no router admitted, failed rollouts, recent failed builds and failing image imports appear on the Problems page.

Operators (OLM)

On clusters with the Operator Lifecycle Manager (OpenShift, or OLM installed from OperatorHub) an Operators (OLM) section lists Subscriptions, ClusterServiceVersions, InstallPlans, CatalogSources, OperatorGroups and Operators, and OLM v1's ClusterExtensions and ClusterCatalogs when they are installed.

• A Subscription shows its channel, approval mode, installed and current CSV ("Upgrade pending" when they differ) and whether its InstallPlan waits for a manual approval.
• A ClusterServiceVersion shows its phase, unmet requirements, owned and required CRDs and the state of its operator Deployments. The copies OLM keeps in target namespaces are marked as copies and link the original; they are never counted as problems.
• Failed operators, failed resolutions, failed or stuck install plans and unreachable catalogs appear on the Problems page. Sextant does not approve InstallPlans.

Virtual clusters (vcluster)

Cluster → Virtual clusters lists the vcluster instances of the connected cluster with their state, version, control-plane pods, Service and kubeconfig Secret. A control plane's StatefulSet or Deployment also shows the objects its syncer copied, with the name and namespace each has inside the virtual cluster.

Click Connect and confirm: Sextant reads the vc-<name> Secret with your credentials (you need get on it), forwards a local port through the host cluster (it shows in Port Forwarding) and adds vcluster_<name>_<namespace>_<host> to the cluster list. The kubeconfig never leaves Sextant's backend; it is kept in a file of this Sextant process only, removed when Sextant closes. The entry lasts only while the port forward runs: disconnecting the host, stopping the forward or quitting Sextant removes it, and you connect again from the same page (the virtual cluster's settings come back).

k3s and RKE2

On a k3s or RKE2 cluster a k3s / RKE2 section appears. Its Distribution page shows which distribution and versions the nodes run, how many servers and agents there are and whether etcd is embedded, and lists the bundled components (CoreDNS, Traefik, the local-path provisioner, metrics-server, ServiceLB, RKE2's charts) with a readable state — including which LoadBalancer Services ServiceLB serves and at which addresses. Addons and etcd snapshots are listed too.

The helm-controller section lists HelmCharts and HelmChartConfigs; a chart's details show whether its install Job succeeded, failed or keeps retrying, with a Logs button for that Job. A node's details show its k3s/RKE2 role and start arguments, with tokens, keys, passwords and datastore addresses always hidden. Failed or retrying chart installs and bundled components that stay unavailable appear on the Problems page.

Secrets inside other objects

Some of these objects carry secrets outside a Secret: a Route's TLS private key, a BuildConfig's webhook secrets, a HelmChart's values, an InstallPlan's manifests, a k3s or RKE2 node's start arguments and environment. AI agents see these fields only when you allow Secret values for that kind (see MCP server), extensions never see them, and the Change timeline records that such a field changed, never its value. The YAML view and the editor show the object as the cluster stores it.