Model deployment topology and environments using deployment-oriented schemas.
Beyond logical structure, you can model how a system is deployed. A separate model with a deployment-oriented schema (such as deployment) describes runtime topology without cluttering the logical architecture.
Separate models for separate concerns
A project can hold multiple models — for example a logical model and a deployment model:
# models.yaml
models:
logic:
deployment:Why separate models
Keeping logical architecture and deployment topology in separate models keeps each view focused. They can evolve independently and still live in one project.
Deployment schema
Set objects_schema: deployment on a deployment model to use runtime object types:
title: Deployment
type: model
objects_schema: deployment
objects:
cluster: nullCommon object types in the packaged deployment schema include:
| Type | Represents |
|---|---|
cluster | Cluster or control-plane scope |
namespace | Logical isolation boundary |
deployment | Declarative Pod/ReplicaSet management |
statefulset | Stateful workload with stable identity |
service | Stable virtual IP / DNS for Pods |
ingress_controller | Data-plane Ingress implementation |
persistent_volume_claim | Pod storage request |
Example deployment object
title: Orders Deployment
type: deployment
description: Deploys orders API pods.
team_owner: platform
owner_email:
- team-platform@example.com
status: activeEnvironments
Use tags to distinguish environments and filter views accordingly:
tags:
- env:prod
- env:stagingModel deployment at the level your team actually operates. If you do not manage Kubernetes directly, a lighter topology may communicate more clearly than a full cluster model.
Last updated on