Working with Personas

Import ApplicationPersonas from running Deployments, and monitor them

​

What is an ApplicationPersona

An ApplicationPersona is a Kubernetes Custom Resource that represents the identity and requirements of an application. It captures:

• Resource constraints: CPU and memory requests/limits
• Scaling parameters: min/max replicas, HPA thresholds
• Health probes: liveness, readiness, and startup checks
• Security policies: security contexts, pod security standards
• Ownership info: team, repository, contact details

Think of it as a living record of your application. Once it is on the cluster, the Dorgu Operator continuously validates the persona against actual cluster state, and the self-healing loop correlates every failure signal to it. A workload without a persona is not watched: it raises no incident and gets no proposed fix.

​

Creating personas

You create personas from the Deployments already running on your cluster with dorgu persona import. It reads each live Deployment and synthesizes a persona from what is already in the spec: resources, probes, replicas, ports, image, and ownership labels. It needs no local source, no Dockerfile, and no relabelling.

1. Find what is not watched

   dorgu health
   

   The Unmonitored section names every Deployment with no persona, with the import command for its namespace.

2. Read the personas import would create

   dorgu persona import -n commerce --all > personas.yaml
   

   YAML goes to stdout and every warning goes to stderr, so the file is clean and you still see what was inferred. Pay attention to inferred resource limits: remediation resizes from the persona, so a limit Dorgu had to derive is one you should check.

3. Create them

   kubectl apply -f personas.yaml
   # or, without the file:
   dorgu persona import -n commerce --all --apply
   

   Committing personas.yaml to the repository your GitOps tool syncs is a good way to keep them under the same review as the rest of your manifests.

4. Monitor status

   dorgu persona list -n commerce
   dorgu persona status order-service -n commerce
   

   The operator reconciles each persona asynchronously. Phase Active means it resolved the persona to its Deployment; Pending means it did not, and the Ready condition says why. See troubleshooting.

You can also write a persona by hand. The CLI quickstart does exactly that for its demo app, and the CRD reference lists every field.

CLI v0.13.0 removed persona generate and persona apply, which built a persona from local source. See the CLI migration guide.

​

Status fields

The persona status command reports the following fields from the ApplicationPersona resource:

Field	Values	Description
.status.phase	Pending, Active, Degraded, Unknown	Current persona lifecycle phase
.status.validation.passed	true / false	Whether validation checks passed
.status.validation.issues[]	array	List of validation issues found by the operator
.status.health.status	Healthy, Degraded, Unknown	Application health status
.status.health.replicas	object	Current and desired replica counts
.status.argoCD.syncStatus	Synced, OutOfSync	ArgoCD sync status (if integrated)
.status.learned.resourceBaseline	object	Resource usage learned from Prometheus

​

What the operator validates

When a persona is applied, the Dorgu Operator runs continuous validation against the workload it describes. The operator checks:

• Resource limits: CPU and memory requests/limits are set and within acceptable bounds
• Replica counts: actual replicas match the declared scaling parameters
• Health probes: liveness and readiness probes are configured and endpoints are reachable
• Security contexts: containers run as non-root, drop capabilities, use read-only root filesystems

The operator never writes to workload resources (Deployments, Services, etc.). It only reads cluster state and updates the ApplicationPersona status fields. This is a core architectural invariant.

​

ClusterPersona

A ClusterPersona is a cluster-scoped CRD, as opposed to the namespace-scoped ApplicationPersona. It represents the identity of the entire cluster: the nodes, the installed add-ons, the total resource capacity, and the cluster’s self-healing policy.

You do not create it. The operator creates one named dorgu-cluster on startup and keeps its discovered fields current. Read it with:

dorgu cluster status

See cluster discovery for what is discovered, and the self-healing trust model for the policy fields you can change.

​

Following changes

To follow persona changes as they happen, watch the CRD directly:

kubectl get applicationpersonas -n commerce -w