Catalog microservices
A catalog item is a reusable image set, one reference per architecture. Many microservices can share that row. The Edgelet node pulls the tag that matches its architecture.
The short map is Registries and catalog. Fields are on Catalog item fields.
When to use it
Use a catalog item when several microservices run the same images, or when you want the image tags in one place. Inline images.amd64 and the other arch fields on the microservice are enough for a one-off service.
The registry row must exist first. remote (id 1) is enough for a public image. Offline images write their own catalog row on registry id 2. That path is separate from this YAML.
System catalog rows ship with the platform (router, NATS, debugger) and use low ids. Leave them in place. Custom items receive higher ids.
What deploy does
potctl deploy -f catalog-item.yaml -n my-ecn
Deploy looks up metadata.name. A missing name creates the item. The same name updates it. spec.id is not the upsert key. The Controller assigns the id on create.
apiVersion: datasance.com/v3
kind: CatalogItem
metadata:
name: reader
namespace: my-ecn
spec:
registry: remote
amd64: ghcr.io/datasance/reader:1.0.0
Set at least one of amd64, arm64, riscv64, or arm. Re-deploy the same name to change tags or spec.registry.
How a microservice uses it
Set images.catalogId to the id from get catalog. You can also refer to the row by its catalog name. Provide catalogId or the per-arch image strings. The image field table is on Microservice fields.
CLI
potctl get catalog -n my-ecn
potctl delete catalogitem reader -n my-ecn
There is no describe catalogitem. get catalog lists ids and tags. delete catalogitem takes metadata.name, resolves it to an id, and deletes. Delete fails for system items and for rows that microservices still reference. There is no attach.
Console
Config → Catalog Microservices lists rows next to registries. See Catalog and templates.