Matching and drift

A resource's service decides who answers for it, so Catalog never guesses silently. This page explains how resources and applications end up in a service, and how the drift report shows where what was declared and what runs disagree.

#How a resource joins a service

Each sweep checks every resource it reports, in this order.

#1. The annotation decides

A resource whose evohub.io/component annotation (or label) names a service's slug is bound to that service:

metadata:
  annotations:
    evohub.io/component: payments-api

• Removing the annotation removes the binding it made, at the next sweep.
• An annotation that names a slug nobody has declared proposes creating that service. Accepting the proposal creates it, named after the slug.
• When the annotated members of an application all name the same existing service, the whole application is bound to it. When they disagree, each keeps its own and the application is left for a person.

#2. A person's decision stands

A binding a person made is never undone by a sweep. If an annotation later disagrees with it, Catalog proposes the annotation's service instead. Accept replaces the person's binding with the manifest's, and from then on the manifest decides. Reject keeps the person's binding and ignores the manifest for good.

#3. Everything else is only proposed

Without an annotation, Catalog proposes, never binds, one service per application, when for example:

• the application's name, or its first workload's app.kubernetes.io/name or app label, is a service's slug
• its name is what a service's repository link ends in
• its workload's app.kubernetes.io/part-of label is a service's slug
• every bound resource in its namespace belongs to one service
• a name or label matches a slug once -, _ and . are ignored (coredns for core-dns), proposed more weakly

An application nothing declared fits is proposed as a new service of its own, named after it. The cluster's own namespaces and the EvoHub agent are never proposed.

Kubernetes labels can hint at the owner: an evohub.io/team, team or owner label, on the namespace or the application's resources, is shown on the proposal when it names one of your teams.

#The match queue

The match queue lists the proposals waiting, strongest first. Open it from the Ownership panel on the Catalog Overview; the Services entry in the navigation shows how many are waiting.

For each proposal:

• Accept puts the application, and everything in it, in that service. A proposal for a service nobody has declared yet creates it, which also needs permission to declare services.
• Reject means this pair is never proposed again.

The confidence a proposal shows only orders the queue; nothing is ever accepted automatically.

#Choosing a service by hand

Open an application or a resource and choose its service. An application's choice applies to every resource in it, now and as resources come and go; a resource bound on its own, by its annotation or by hand, keeps its own.

Unbinding a resource that carries an evohub.io/component annotation lasts only until its next sweep, because the manifest still says so. To move it for good, change the manifest.

#Drift

Open Drift from the Catalog Overview (All drift). You can narrow it to one environment. Each section lists at most 100 entries; the Resources list filters show the rest.

#Exposed cloud resources

Cloud machines and services whose security groups open an admin port, such as SSH, RDP or a database, to the whole internet are counted under Exposed on the Overview, and marked on the cloud account's map. See Cloud accounts.

#Images

Inventory → Images lists every container image your resources run, most used first, with the environments it runs in. Images pinned to latest, or with no tag and no digest, are marked as floating: they run whatever the registry held when their pods last started. Select an image to see the resources that run it.

#Related

• Catalog overview
• Get started with Catalog
• Catalog API