Ecosystem views

Ecosystem views

Many clusters run operators whose state lives in custom resources: Knative, Crossplane, Kyverno, External Secrets, CloudNativePG, Strimzi, Prometheus Operator, Traefik, Contour, Sealed Secrets, Reflector. Any custom resource is already listed under Custom Resources, but its YAML rarely says plainly whether it works. For these projects Sextant has its own sidebar sections, with the operator's status explained in plain words, the links between objects, and problems on the Problems page. Argo Rollouts and Argo Workflows have their own page: Argo Rollouts and Argo Workflows.

Contents: How the sections work · Knative Serving · Knative Eventing · Crossplane · Kyverno · External Secrets · CloudNativePG · Strimzi · Prometheus Operator · Traefik · Contour · Sealed Secrets · Reflector · Problems · What Sextant does not do

How the sections work

• Only what the cluster has. A section appears only when the cluster serves at least one of its kinds, and lists only the kinds it serves, at the version it serves. An operator installed after you connected shows up without reconnecting. Nothing is watched before Sextant knows the kinds are there.
• The operator's own verdict. Each view reads the conditions and status fields the operator writes and says what they mean; Sextant does not guess whether something is healthy by other means.
• Read-only. These views add no actions. Their objects have the usual Edit and Delete under the usual confirmations, and nothing else is written to the cluster.
• A counter on each section header shows how many of its objects need attention (see Problems).

Knative Serving

Section Knative: Services, Configurations, Revisions, Routes and Domain Mappings (serving.knative.dev).

• Tables have a Status column (Ready, Progressing, Failed) with the reason of the failing condition, and the URL, latest created and latest ready revision, traffic or replicas where they apply.
• Details explain the first condition that fails (ConfigurationsReady, RoutesReady, ContainerHealthy, ResourcesAvailable…) in a sentence, for example "The latest revision web-00004 failed (ContainerMissing). Traffic stays on web-00003, the last revision that became ready."
• Traffic shows the split between revisions, with tags, the share of each and whether it follows the latest revision, as links to the Revisions. While Knative has not applied a new split yet, the asked one is shown and marked "asked, not yet in effect".
• A Revision shows its actual and desired replicas, images, requests per container at once and request timeout. A revision that is scaled to zero is Ready, not failed: the first request starts a Pod.

Knative Eventing

Section Knative Eventing, next to Knative Serving's (either half can be installed without the other): Brokers, Triggers, Channels, In-Memory Channels, Subscriptions, Sequences, Parallels and the sources (ApiServerSource, PingSource, ContainerSource, SinkBinding, KafkaSource), each listed only when the cluster serves it.

• State is the object's own Ready condition, as for Serving. The details name the first failing condition (IngressReady, FilterReady, SubscriberResolved, SinkProvided, SufficientPermissions…) and the destination that did not resolve.
• Destinations (a Trigger's subscriber, a source's sink, a Subscription's subscriber and reply) are links to the object they name, whatever its kind (a Knative Service, a Service, a Broker, a Channel), with the address Knative resolved. A Trigger's filter is shown as Knative reads it: the attributes that must match (an empty value matches any value) or, when spec.filters is set, the CloudEvents filter expressions, which then override the simple filter.
• The event path in the details is a tree: sources → Broker → its Triggers → subscribers; sources → Channel → its Subscriptions → subscribers and replies; a Sequence's steps in order, then its reply; a Parallel's branches. It is read from one namespace only, the one of the object you opened, so a source in another namespace that sends to a Broker across namespaces is not listed among its senders. A fan-out shows at most 50 items and counts the rest.

Knative creates many of these objects itself (a Broker's backing channel, a Trigger's Subscription, a Sequence's channels). Problems are therefore told through the owner: a Trigger whose only failure is its Broker's is told through the Broker, and an object controlled by another Eventing object is told through that one, so one broken Broker is one problem, not a dozen. Eventing problems are in the Knative category (see Problems). Other eventing kinds (KafkaChannel, IntegrationSource, JobSink, third-party sources) appear only under Custom Resources.

Crossplane

Section Crossplane: Composite Resource Definitions (XRDs), Compositions, Providers, Configurations, Functions, and the page Composite Resources.

• XRDs say whether they are established and which composite kind and claim kind they define. Providers, Configurations and Functions say whether the package is installed and healthy, with its current revision.
• Claims, composite resources and managed resources (of any provider) get a Crossplane section in their details: their role, Synced and Ready, the first failing condition with its reason and message, the Composition, the connection Secret and, for a managed resource, its ProviderConfig, external name, deletion and management policies. Both the classic (v1) and the v2 field layouts are read.
• The chain. Resources in the details follows a claim to its composite resource and the composite to its composed resources, each with its state; a managed resource links up to its composite. The objects are read when you open the details and again when the shown object changes.
• Paused is its own state: an object whose reconciling is paused (annotation crossplane.io/paused: "true", or management policies that pause it) is shown as Paused, never as failed, and is not a problem.
• Composite Resources lists the claims and composite resources of every kind the XRDs define, in all namespaces, with their kind, state, Synced, Ready, reason and Composition, and an Only problems filter.

Limits: the claim and composite kinds of at most 20 XRDs (the first by name) are listed and judged, at most 5000 objects per kind, and at most 30 objects of a chain are read; each limit is stated on the page when it is reached.

Kyverno

Section Kyverno: Cluster Policies, Policies, Policy Reports, Cluster Policy Reports, and Kyverno's Ephemeral Reports and Cluster Ephemeral Reports (listed only; they are intermediate results that end up in the policy reports).

• A policy shows whether it is ready (Kyverno applies it), its Mode — Enforce (a request that breaks a rule is refused), Audit (it is let through and the failure goes into a report) or Mixed when its rules differ (per-rule modes since Kyverno 1.13) — whether it runs background scans, and its rules with type, mode and kinds. Results in reports sums up passes, failures, warnings, errors and skips of the policy over the reports that carry its label, in all namespaces for a ClusterPolicy and in its namespace for a Policy.
• Every object — a Deployment, a Pod, a Namespace, anything Kyverno checks — gets a Policy results section in its details: the policies and rules checked against it, with their results and messages. Sextant reads the one report Kyverno 1.10 and later writes for that object, not the namespace's whole list of reports.
• Reports show their counts and results with the object each one is about.

Kyverno older than 1.10 (one report per namespace) shows no per-object results and no policy summary; its reports are still listed.

External Secrets

Section External Secrets: External Secrets, Cluster External Secrets, Secret Stores, Cluster Secret Stores and Push Secrets.

• An ExternalSecret shows whether its last sync worked (Ready, Pending, Failed) with the reason and the Last error, its refresh interval and last sync, the store (and whether that store is ready), the target Secret as a link, its creation policy, and the Keys: each Secret key with the remote key and property it comes from, and the keys taken in bulk (dataFrom).
• Stores show their provider, whether they validate, and their capabilities. A ClusterExternalSecret shows the namespaces it created its ExternalSecret in, and those that failed with the reason. A PushSecret shows its source Secret, stores and pushed keys.
• No secret data. Only the names of keys are shown, never their values. Sextant does not read the target Secret to show what was synced; it links it, and a Secret's values are shown only when you press Show in its own details, as for any Secret.

CloudNativePG

Section CloudNativePG: Clusters, Backups, Scheduled Backups and Poolers.

• A Cluster shows its state in words — Healthy, Switchover (the primary is moving from one instance to another), Failing over, Progressing, Unhealthy — with the operator's phase, ready instances of desired, the current and target primary, image and storage, continuous archiving, the last successful and last failed backup and the earliest point it can be recovered to.
• Instances lists each instance with its role (Primary or Replica), health and timeline.
• Hibernation. A Cluster hibernated on request (annotation cnpg.io/hibernation: "on") is shown as Hibernating while its pods are deleted and Hibernated once they are gone, with its volumes kept; it is never a problem, although the operator leaves its phase and ready instances as they were.
• Backups show their method, target, start and stop, backup ID and destination; Scheduled Backups their schedule, whether they are suspended, last and next run; Poolers their type, instances and pool mode.

Strimzi

Section Strimzi: Kafkas, Kafka Node Pools, Kafka Topics, Kafka Users, Kafka Connects, Kafka Connectors and Kafka MirrorMaker 2.

• Each object is Ready, Not ready (with its reason) or Pending, from Strimzi's Ready and NotReady conditions. Strimzi's Warnings (deprecated fields, for example) are listed in the details and never count as a problem.
• A Kafka shows its version, metadata state, cluster ID and node pools, and its Listeners with the type, port, TLS and the bootstrap address and addresses Strimzi reports for each. A node pool has no readiness of its own; its roles, replicas, node IDs and storage are shown.
• Topics show partitions, replication factor and config; Users their authentication, authorization (with the ACL rules) and the Secret holding their credentials, as a link (its data is not read). Kafka Connect shows its REST address, connector plugins and connectors; MirrorMaker 2 its mirrors.
• Kafka Connectors are listed too. A connector and each of its tasks show their state (running, paused, failed…) and worker as Kafka Connect reports it, which Strimzi copies into the connector's status. Nothing is asked of Kafka Connect itself.
• Failures. A failed connector or task is a problem at once and replaces the generic "not ready" one, whose text only says to look at the status. The problem carries the first line of the failure's stack trace (on a MirrorMaker 2 prefixed with the connector's name: a MirrorMaker 2 with a failed task stays Ready, so this is the only place it shows). The details show each failure with its trace folded.
• Auto-restart. When a KafkaConnector has autoRestart enabled and has restarts left (maxRestarts), Strimzi may cure the failure itself, so it counts as a problem only from the end of Strimzi's next restart window (plus two minutes for its reconciliation); a failure a restart cures never notifies. Restarts back off (up to an hour apart), and without maxRestarts the wait stops growing after 7 restarts, about three hours in all. The details say when Strimzi stopped restarting because maxRestarts is reached. A MirrorMaker 2's auto-restart is set per mirror and is not matched to its connectors, so its failures count at once.

Prometheus Operator

Section Prometheus Operator: Service Monitors, Pod Monitors, Probes, Prometheus Rules, Prometheuses and Alertmanagers.

• A ServiceMonitor or PodMonitor shows the namespaces it looks in and its selector, and Selects now: the Services (or Pods) its selector matches right now, with the endpoints' ports and whether each port name is found on them ("on 2 of 3"). "Selects no Service: Prometheus scrapes nothing for it." is the usual reason a target is missing in Prometheus.
• Picked up by names the Prometheus (or PrometheusAgent) objects whose selectors match the monitor's labels and namespace, or says that none does. A Prometheus that ignores monitors' namespace selectors (ignoreNamespaceSelectors) is taken into account.
• A Prometheus or Alertmanager shows whether it is available (Available, Degraded, Failed, Pending) with the reason, its replicas, shards, version, retention and whether it is paused. A Prometheus also shows What it picks up: its selectors and namespaces for ServiceMonitors, PodMonitors, Probes and PrometheusRules.
• A PrometheusRule lists its groups with their alerting and recording rules; a Probe its prober, module and targets.

Selectors are read the way the operator reads them: a missing selector selects nothing, an empty one everything. The Services or Pods are listed by the selector on the API server, in at most 20 namespaces; a monitor of every namespace is listed cluster-wide by its selector, and an empty selector over every namespace is not listed at all.

Traefik

Section Traefik (shown when the cluster serves Traefik's CRDs): IngressRoutes, IngressRouteTCP and UDP, Middlewares, MiddlewareTCPs, TLSOptions, TLSStores, TraefikServices and ServersTransports. Kinds in the older traefik.containo.us group, where the cluster still serves them, are listed with the group in their name.

Traefik writes no status on any of these objects. A route it refuses is only a line in Traefik's log, so there is no "Ready" to read. Sextant therefore judges one thing it can see: whether the references of an object lead anywhere. The status column says References found, Broken reference or Not all checked, and never "Ready".

• Broken: a Middleware, Service, TraefikService or TLSOption that does not exist; a service kind other than Service or TraefikService; a route with an empty match. A missing target in another namespace is broken whatever Traefik's settings say. The details list each reference and what it points at, as links.
• Unknown, never broken and never fine: a reference into another namespace whose target exists, because whether Traefik follows it depends on allowCrossNamespace in its static configuration, which no Kubernetes object shows (the details say so); a name@provider reference to another provider (@internal ones are Traefik's own and always exist); and a list that could not be read or was capped.
• A route's TLS never breaks it. Traefik builds the router whether or not its certificate loads and serves a default certificate otherwise, so a missing TLS Secret of an IngressRoute is not a broken reference. The Secret references of Middlewares and TLSOptions are checked in the details of one object while they are open (names only; no Secret value reaches the window), never in the background, so a missing one is shown there and not as a problem.
• Both groups. Where a cluster serves a kind in both traefik.io and traefik.containo.us, a reference from a traefik.io object is looked up in traefik.io; a target only in the old group is "legacy only", open and not judged. The details say when the other group holds an object of the same name.
• Problems. The Traefik category lists broken references, after a 2-minute grace (objects are often applied in the wrong order). It is off by default, because it lists every Traefik object of the cluster and the Services they name; turn it on with Traefik references on the Problems page or under Notify about (the same setting). The section counter shows nothing while it is off.
• Diagnose on an IngressRoute opens the Traffic diagnosis: entry points (with the note that Traefik writes no status), TLS, then for each route its rule, each middleware and each service, on into the Service's own checks; a TraefikService is followed through its weighted, mirroring and failover children. IngressRouteTCP and UDP are not diagnosed.

Traefik's own reasons for rejecting a route (a syntax error in a match rule, an entry point Traefik does not have, an ingress class its provider ignores, allowExternalNameServices off) cannot be seen from the objects: such a route is shown as fine or unknown, and the details say Traefik writes no status. Traefik objects are read in all namespaces (at most 5000 per kind); Services are listed by name only, in at most 40 namespaces, and references beyond that stay unknown.

Contour

Section Contour (shown when the cluster serves projectcontour.io): HTTPProxies, TLS Certificate Delegations and Extension Services.

• State is what Contour wrote: an HTTPProxy is valid, invalid or orphaned (an included proxy no root reaches), or not processed yet when no Contour has looked at it. The details explain the reason in words (duplicate virtual host, root proxy not allowed in the namespace, an include that creates a cycle, delegation not permitted…) and list every error and warning. Sextant does not re-validate a proxy.
• Served in part. After some errors (an unresolved service, an include that is not found, a root that includes a root, duplicate or invalid match conditions) Contour still serves the rest of the proxy and answers 502 or 503 for the failed part; the details say "in part". Any other error drops the virtual host or every route of the proxy: "rejected".
• Services and weights are shown as Contour programs Envoy: with no weight on any service of a route the split is equal; if some have a weight, a service without one gets nothing; a mirror takes no share and copies the percentage its weight says. Services are always looked up in the proxy's own namespace.
• The includes tree. A root shows everything it includes, with the path prefixes joined from the root down the way Contour joins them (/api + /v1/ = /api/v1/; slashes collapsed, a trailing slash kept). An included proxy shows the roots that reach it and the branches that lead to it. A missing include, a root that is included and a cycle are marked. The tree is drawn from the cluster-wide HTTPProxy watch the problems use, at most 200 nodes and 5 roots; with more than 5000 proxies it may be incomplete and says so.
• TLS shows the Secret, and for a Secret in another namespace the TLS Certificate Delegation that allows it, looked up in the Secret's namespace.
• Root namespaces are invisible. Contour's --root-namespaces flag is not visible to Sextant; a root outside them is told only by Contour's own error, and the words say that the flag exists. The same for ExternalName Services (enableExternalNameService): they get a warning, not a verdict.
• Problems. The Contour category (on by default) lists invalid proxies, named by Contour's first error, and orphaned ones, after a 2-minute grace. A proxy not processed yet is no problem. An orphan below an invalid proxy is told through that proxy: Contour stops at an invalid root and marks everything it includes orphaned, so one bad TLS Secret on a root with 20 includes is one problem, not 21.
• Diagnose on an HTTPProxy opens the Traffic diagnosis: Contour's state first, then for a root the host, the address Contour reports, the delegation and the certificate; then per route and per service the Service's own checks, and per include its existence, its state and what is below it (3 levels, 30 services). An include in a namespace the diagnosis does not read is "unknown", never "fine".

Sealed Secrets

Section Sealed Secrets (shown when the cluster serves bitnami.com): the SealedSecrets of the Bitnami Sealed Secrets controller.

• The controller's own verdict. The table has Status (Synced, Failed, Pending), Scope, Keys and Message. Status is the Synced condition the controller writes: Synced when it is True for the current generation, Failed when it is False (the controller's error is shown as the Last error), Pending when there is no condition yet or the status is of an older generation than the object's. With no condition at all, the details say the controller may not be running, or runs with --update-status=false. Sextant does not try to work out whether a SealedSecret can be decrypted: that needs the private key.
• Errors in words. Known controller errors are explained: no key can decrypt it (it was sealed with another controller's certificate, or for another name, namespace or scope), a Secret of that name exists and is not managed by this SealedSecret (the details name the sealedsecrets.bitnami.com/managed: "true" annotation), an immutable target Secret, and the deprecated spec.data. The controller's events are in the details' own Events section.
• Scope is read from the SealedSecret's annotations as the controller reads them: Strict (unseals only under this name in this namespace), Namespace-wide (any name in this namespace) or Cluster-wide (any name, any namespace).
• The target Secret is the SealedSecret's own name in its namespace, linked from the details with how it stands: managed by this SealedSecret, taken over or patched by annotation, controlled by another object, not managed, not found. Sextant reads that Secret's metadata only, never its values.
• Keys by name and size. Of spec.encryptedData only the key names and the size of each sealed value are shown, never the sealed text itself, and no value of any kind. The template shows the Secret's type, whether it is immutable, whether owner references are skipped, and the names of its template keys.
• The controller is looked up while the details are open (the Deployment sealed-secrets-controller in kube-system, or any Deployment labelled app.kubernetes.io/name=sealed-secrets): its readiness and image. A controller under another name without that label is reported as not found, with a note that it may run under another name. The sealing keys are listed from the key Secrets next to the controller (at most 5): name, active or compromised, and when each was created, which shows when the key was last renewed. Metadata only.
• The sealing certificate is never read or shown. The public certificate sits in the same Secret as the private key, so reading it would mean reading the private key; Sextant does not. The details say the certificate is not shown and why. Sextant also never asks the controller for it over HTTP.
• Problems. The Sealed Secrets category (off by default, see Problems) lists a SealedSecret that failed to unseal for the current generation (after 5 minutes, with the controller's message), and one that is Synced but whose target Secret is missing (after 2 minutes). A "Secret missing" is judged only in the first 20 namespaces with synced SealedSecrets, and only when the Secrets of a namespace were read in full; if a list is forbidden, cut short or not read, the Secret is "not known", never "missing" (the details still look the Secret up by name).

Reflector

Reflector copies Secrets and ConfigMaps between namespaces. It defines no resource kind and writes no status: everything is in annotations (reflector.v1.k8s.emberstack.com/…) on ordinary Secrets and ConfigMaps. So there is no sidebar section: Reflector shows up where the objects are.

• A Reflection column on the Secret and ConfigMap tables (hide it like any column), and a Reflection section in the details of an object that carries Reflector's annotations.
• A source shows whether reflection is allowed, the allowed namespaces and namespace selector, whether automatic mirrors are enabled and in which namespaces, and the mirrors found: namespace, manual or automatic, and state. Automatic mirrors that Reflector would not create because the name is taken are marked Name taken.
• A mirror shows its source (as a link) and its state, judged as Reflector judges: In sync (the version it copied is the source's current resourceVersion), Stale (the source changed since; Reflector usually catches up in seconds), Source missing (Reflector leaves a manual mirror as it is and deletes an automatic one), Not allowed (the source no longer allows the mirror's namespace: Reflector stops updating a manual mirror and deletes an automatic one), or Cannot tell.
• Values are never read or compared. The state comes from Reflector's own annotations and the source's resourceVersion; a value or a hash of one is never needed.
• Namespace patterns are evaluated in the backend, with linear-time regular expressions. Reflector's allowed-namespace lists are comma-separated regular expressions, each of which must match the whole name; an empty list allows every namespace, and a label selector is ORed with it. A regular expression from a cluster object could freeze a window that ran it, so Sextant matches the patterns in the core with a regex engine whose time is linear in the pattern and the name, with size limits (at most 256 characters per pattern, 64 patterns and 2000 names per call). Syntax that engine refuses, or that .NET and Rust read differently (backreferences, lookaround, atomic groups, some escapes and flags), is not run.
• Cannot tell, never a guess. A pattern that cannot be run that way (the details name it and say why), a namespace whose labels are not known, a source whose namespace could not be read, or a moment before the backend has answered all give Cannot tell, never "allowed" or "in sync". A selector Reflector cannot parse matches no namespace, and the details say so.
• Bounded. Only metadata (names, annotations, resourceVersions) of the namespaces in view is watched, at most 40 per kind; a source allowed in more namespaces has the rest listed as "not checked". There is no cluster-wide Secret list, except for the opt-in problems.
• Problems. The Reflector category (off by default, see Problems) lists a mirror whose source is missing (after 2 minutes), a stale mirror (after 10 minutes), and a mirror the source no longer allows (after 10 minutes). Cannot tell is never a problem. Finding every mirror needs a cluster-wide metadata list of all Secrets and ConfigMaps (each capped at 10 000 objects; the Problems page then says the list is incomplete), which is why it is opt-in.

Problems

Each project has a problem category. Most are on by default; Kyverno policies, Prometheus Operator, Traefik, Sealed Secrets and Reflector are off until you turn them on, because they can be large and lasting rather than incidents, or cost a watch of every object of the project.

Category	Problems	By default
Knative	A Service that is not ready, or a Configuration that is not (one a Service owns is told through the Service), after 2 minutes. Only the latest revision's failure counts; an old revision that failed is history. Also every Eventing kind the cluster serves (Brokers, Triggers, Channels, Subscriptions, Sequences, Parallels, sources) that is not ready, told through its owner or Broker where Knative made it.	on
Crossplane	A claim or composite resource that is not Synced, or not Ready for another reason than being created or deleted, after 2 minutes; one still being created after 30 minutes. A composite is told through its claim. Paused and deleting objects are never problems.	on
External Secrets	An ExternalSecret, ClusterExternalSecret or PushSecret whose sync failed, and a store that does not validate.	on
CloudNativePG	A Cluster that is not healthy (after 5 minutes), whose continuous archiving or last backup fails; a failed Backup, for a day after it stopped. A hibernated Cluster is not a problem.	on
Strimzi	A Kafka, topic, user, Connect or MirrorMaker 2 that is not ready after 5 minutes; a failed connector or task at once, unless auto-restart can still cure it.	on
Contour	An invalid HTTPProxy, named by Contour's first error, and an orphaned one (not one below an invalid proxy), after 2 minutes.	on
Sealed Secrets	A SealedSecret that failed to unseal (after 5 minutes, with the controller's message), and a Synced one whose target Secret is missing (after 2 minutes).	off
Reflector	A mirror whose source is missing or stale, or that the source no longer allows. "Cannot tell" never.	off
Kyverno policies	An object with failed policy results (one problem per object, naming the policies). A rule that could not be evaluated is listed as a problem of its own, but does not notify.	off
Traefik	An object with a broken reference (a missing Middleware, Service, TraefikService or TLSOption), after 2 minutes. Cross-namespace references are unknown, not broken.	off
Prometheus Operator	A ServiceMonitor or PodMonitor that selects nothing; a Prometheus or Alertmanager that is not available, degraded or not reconciled (after 5 minutes). A monitor no Prometheus picks up is shown as a warning, never notified or counted, and only when the cluster has a Prometheus object at all.	off

Turn the five opt-in categories on with Kyverno policy failures, Prometheus Operator monitors and servers, Traefik references, Sealed Secrets unsealing and Reflector mirrors on the Problems page, or under Notify about in Settings → General → Notifications (the same setting). Turned on:

• Kyverno policies watches the PolicyReports and ClusterPolicyReports of the whole cluster (at most 5000 of each kind).

• Prometheus Operator watches the monitors and Prometheus objects in all namespaces, and the names and labels of the Services and Pods in the namespaces the monitors look in, at most 40 namespaces. A monitor of every namespace, or of more namespaces than that, is never reported as selecting nothing; its details still show what it selects.

• Traefik watches every Traefik object of the cluster (at most 5000 per kind) and the names of the Services they reference.

• Sealed Secrets watches every SealedSecret of the cluster (at most 5000) and the names and metadata of the Secrets in the namespaces whose SealedSecrets say Synced (at most 20 namespaces and 5000 objects; beyond that a missing Secret is not judged and the Problems page says the list is incomplete).

• Reflector watches the names, annotations and resourceVersions of every Secret and ConfigMap of the cluster (each capped at 10 000 objects), never their values.

Strimzi topics and users are watched up to 5000 of each. When a list is cut short, the Problems page says it is incomplete.

AI agents do not get these categories from get_problems.

What Sextant does not do

• It installs, configures or upgrades none of these operators, and runs none of their CLIs (kn, crossplane, kyverno, kubectl cnpg…). It never sends a request through Traefik or Contour.
• It does not trigger syncs, backups, switchovers, hibernation, connector restarts or reconciles; use the operator's own tools, or change the object with Edit.
• It does not read Secret values for External Secrets, Strimzi users, CloudNativePG, Sealed Secrets or Reflector (nor the Sealed Secrets sealing certificate), does not read Traefik's or Contour's static configuration or logs, and does not talk to Prometheus, Kafka, Kafka Connect or a database: everything comes from the Kubernetes API.
• AI agents and extensions get nothing new from these views.

Next: Argo Rollouts and Argo Workflows, Problems and notifications, Using Sextant.