Applications

Kubernetes has no object called "application". A service your team calls checkout is a Deployment, a few ConfigMaps and Secrets, a Service, an Ingress and an autoscaler, sometimes spread over several namespaces. Protecting it or asking what changed in it object by object is slow and easy to get wrong.

What you get

• An Applications page in the dashboard that lists every application Telark found, with its health, namespaces, workloads, images and the protection plans that cover it.
• One unit for everything else Telark does: protection plans can scope to applications, change history and rollback are per application, and Insights are grouped by application.
• Nothing to declare. You don't create Application objects; Telark builds them from the labels your workloads already carry.

How it works

The discovery service watches these kinds in every namespace that is not excluded:

Grouping

Each resource is assigned to an application by the first label that is set, in this order:

1. app.kubernetes.io/name
2. app.kubernetes.io/part-of
3. app.kubernetes.io/component together with app.kubernetes.io/instance (a -release suffix on the instance is dropped)
4. app

The label value names the application: it is lowercased and _ becomes -. A value that is still not a valid Kubernetes object name is skipped and logged once. The same label value in several namespaces gives one application that spans them.

A resource without these labels joins the application of its owner (a ReplicaSet's Deployment, for example), or else the application in the same namespace whose name its own name contains. A ConfigMap or Secret joins the application of the workload that references it. Jobs started by a CronJob are folded into the CronJob, and cluster noise such as kube-root-ca.crt, default service accounts and Helm release Secrets is ignored.

Health

Health is derived from workload readiness: healthy, degraded, down or unknown, with ready and total replicas. A move to degraded or down is recorded as an incident change, and the return to healthy as a recovery (see Change history and rollback).

Keeping up with changes

Events are buffered per application for a few seconds, so a rollout or a multi-field edit is recorded as one change, not dozens. Every discovery replica serves the API and processes per-application work under a per-application lock in Redis; one elected leader records informer changes and runs the plan and rollback controllers. Adding replicas does not duplicate work.

Discovery publishes each application on NATS, and the notifier persists it as an Application resource (applications.telark.io) through the exporter. When every workload of an application is gone, the application is removed after two empty cycles.

Plan coverage

Each application card lists, under Protected by:

• Enforcing now: an active plan whose scope includes the application, directly or through one of its namespaces.
• Scheduled or awaiting approval: a scheduled or pending_approval plan that will cover it.

Failed, canceled and terminated plans don't count. A plan's kind or resource exclusions do not remove the application from its coverage.

Excluded namespaces

Namespaces listed in spec.excludedNamespaces of the TelarkConfig resource are not discovered, not shown on any page and refused as plan targets. A fresh install excludes default, kube-system, kube-public and kube-node-lease. Change the list under Settings (Contributor on settings).

Force sync and reset

• Sync re-runs discovery for one application now (POST /api/v1/applications/{name}/sync). The job is queued on a Redis stream, one per application at a time, and its progress is recorded in status.lastForceSync.
• Reset deletes the application's record and snapshots and clears its discovery state (POST /api/v1/applications/{name}/reset). While its workloads still exist, discovery recreates it from scratch.

Limits

• Grouping is label-based. Set app.kubernetes.io/name on your workloads for predictable application names; a workload that carries none of the labels above, and has no owner that does, is not grouped under a name you chose.
• Users can edit only an application's display name and description. Membership always follows the cluster.
• Discovery covers one cluster: the one Telark is installed in.

Reference

• Application resource
• Applications API
• Discovery environment variables