Workloads
Workloads are Controller objects. They are not Kubernetes custom resources. The short map is Workload orchestration. This section is the field-level guide.
Deploy a file with potctl. The command is deploy -f. There is no apply.
potctl deploy -f workloads.yaml -n my-ecn
When one file holds several documents, the CLI sorts by kind. Write the file in an order a person can read. The CLI still uses its own kind order.
Kinds
| Kind | Role |
|---|---|
ApplicationTemplate | Parameterized blueprint for a whole app. Not a running container. See Application templates. |
MicroserviceTemplate | Parameterized blueprint for one service. See Microservice templates. |
Application | Named group. NATS account policy lives here. It may list inline microservices or point at a template. See Applications. |
Microservice | One container on one Edgelet node (spec.agent.name). See Microservices. |
In YAML the node is kind: Agent. In prose it is an Edgelet node.
The CLI name is application/microservice.
potctl describe microservice myapp/api -n my-ecn
potctl logs microservice myapp/api -n my-ecn
A standalone kind: Microservice may set metadata.name to the service name and spec.application to the group, or set metadata.name to myapp/api.
System applications
Datasance PoT creates a system application for each Edgelet node, named system-<agentName>. That application holds the router, NATS, and debug microservices the platform creates. How those fabrics are declared is on Networking.
Operators inspect them with get system-microservices and describe system-microservice. They do not deploy them as user kind: Application documents.
potctl get system-microservices -n my-ecn
potctl describe system-microservice system-edge01/debug -n my-ecn
What a microservice consumes
A catalog item supplies the image set. Fleet models and knowledge bind through spec.models and spec.knowledge. Those pages stay the catalog reference. This section only shows how a workload names them.
Two microservices on the same Edgelet node can reach each other by name on the bridge. The short name is myapp.worker, and the full name is myapp.worker.svc.bridge.local. See Bridge DNS and DNS.
Deploy order
Create the objects a microservice names before that microservice:
- Registry, catalog item, model, and knowledge exist before the microservice that names them.
- A NATS account rule exists before an application with
natsConfig.natsAccess: true. - A NATS user rule exists before a microservice with
natsConfig.natsAccess: true. - The Edgelet node in
spec.agent.nameis already registered. - Templates exist before the application or microservice that points at them.
A workload-focused kind order:
Secret → ConfigMap → Role → RoleBinding → ServiceAccount
→ NatsAccountRule and NatsUserRule
→ ApplicationTemplate → MicroserviceTemplate
→ Registry → Model → Knowledge → RuntimeClass → CatalogItem
→ Application → Microservice
YAML parsing
| Kind | Parsing | What that means |
|---|---|---|
Microservice | Strict | Unknown keys fail at deploy. |
Application | Non-strict | Check the result with describe application. |
ApplicationTemplate | Non-strict | Prefer documented fields. Extra keys may be ignored. |
MicroserviceTemplate | Non-strict | Same as an application template. |
EdgeOps Console
Running applications and microservices are under Workloads. Templates and catalog items are under Catalog and templates. There is no Configure → Workloads menu.
The first deploy is still potctl deploy -f. Console lists, edits, and runs start, stop, logs, and exec after the objects exist.
Primers
Related
- Applications and Application fields
- Microservices and Microservice fields
- NATS access
- Logs and exec
- Node logs and exec for the node daemon, not the container