Workload orchestration
Datasance PoT stores the software you run as objects on the control plane, then places containers on Edgelet nodes. This section is a short map of those objects. Field tables stay in Learn.
You deploy a file with potctl deploy -f. There is no apply command.
When one file holds several documents, the CLI sorts by kind, not by file order. Write the file in an order a person can read. The CLI still uses its own kind order.
Four layers
Templates are blueprints. An application template describes a whole app. A microservice template describes one service. A template is not a running container. Instantiation points at the template from the application or the microservice.
Runtime workloads are what you actually start. An application is the named group. NATS account policy lives on that group. A microservice is one container in the group. The CLI name is application/microservice.
Placement puts that container on one Edgelet node. In YAML the node is kind: Agent.
Config objects are what those workloads consume: registries, catalog items, models, knowledge, config maps, secrets, volume mounts, and volumes. The microservice names them. It does not paste their contents into the application file.
---
apiVersion: datasance.com/v3
kind: Application
metadata:
name: line-monitor
metadata.name is the group. Microservices, templates, and config objects refer to that name.
Order that works
Secrets and config maps come before volume mounts, and before env values that use valueFromConfigMap or valueFromSecret.
A registry comes before a model, a knowledge artifact, and a catalog item.
A catalog item comes before a microservice that names it.
An application comes before its microservices, or in the same file with them.
Pages in this section
- Applications and microservices
- Templates
- Registries and catalog
- Models and knowledge
- Config, secrets, and volumes
Also on the cluster
These objects do not have Get Started pages. Read them in Learn: