GGolem TechnologiesDeployment guide
Azure AKS · Controlled deployment resource
Azure Marketplace · Azure Kubernetes Service

Bounded Agentic AI Workflow Engine on AKS

A deployment and operations guide for a buyer-owned Azure Kubernetes Service installation using the published Azure Marketplace extension.

Prepare deployment Open Azure Marketplace Watch Azure implementation videos
Overview

Deploy through Azure Marketplace into buyer-owned AKS

The Bounded Agentic AI Workflow Engine is delivered as an Azure Kubernetes Application extension. It runs inside the buyer’s Azure subscription and AKS cluster, using buyer-controlled networking, PostgreSQL, Blob Storage, identities, secrets and exposure policies.

Deployment boundary. This guide assumes a prepared Azure landing zone. The Marketplace extension installs the application lifecycle into AKS; it does not replace the buyer’s subscription governance, network design, database, storage account, DNS, certificates or operational controls.
Customer-hosted architecture

Azure-native deployment with buyer-controlled state

Scope and landing-zone assumptions

Marketplace extension, not an entire Azure landing zone

IN

Managed by the offer

The Kubernetes application extension, namespaced workloads, services, model job orchestration and configured runtime bindings.

OUT

Prepared by the buyer

AKS, node pools, PostgreSQL, Blob Storage, networking, identity governance, DNS, certificates and external access.

The package uses a system node pool for control-plane workloads and a GPU node pool labelled sku=gpu and tainted sku=gpu:NoSchedule. The buyer selects a supported GPU VM family and ensures that the required capacity and quota are available.

Prerequisites

Prepare the Azure landing zone

  • Azure subscription with access to the published Marketplace offer
  • Existing AKS cluster with appropriate API access and network controls
  • System node pool and supported GPU node pool
  • Azure Database for PostgreSQL reachable from AKS
  • Blob Storage account and required containers
  • Azure Workload Identity enabled for the cluster deployment path
  • Azure Monitor configuration appropriate to buyer operations
  • Permissions to deploy and manage Kubernetes extensions
Azure subscription and AKS access

Connect to the intended buyer cluster

Set only buyer-owned identifiers. Run the remaining command blocks in the same shell so the exported values remain available.

Terminal — Azure and AKS context
set -euo pipefail

for tool in az kubectl jq curl python3; do
  command -v "$tool" >/dev/null 2>&1 || {
    echo "Missing required tool: $tool" >&2
    exit 1
  }
done

read -r -p "Azure subscription ID: " SUBSCRIPTION_ID
read -r -p "AKS resource group: " AKS_RESOURCE_GROUP
read -r -p "AKS cluster name: " AKS_CLUSTER_NAME
read -r -p "Extension resource name [tacr-workflow-mvp]: " EXTENSION_NAME
EXTENSION_NAME="${EXTENSION_NAME:-tacr-workflow-mvp}"
read -r -p "Release namespace [tacr]: " K8S_NAMESPACE
K8S_NAMESPACE="${K8S_NAMESPACE:-tacr}"

export SUBSCRIPTION_ID AKS_RESOURCE_GROUP AKS_CLUSTER_NAME
export EXTENSION_NAME K8S_NAMESPACE
export EXTENSION_TYPE="GolemTech.TacrWorkflowMVP"
export HELM_RELEASE="tacr"
export API_DEPLOYMENT="${HELM_RELEASE}-tacr-platform-api"
export API_SERVICE="${HELM_RELEASE}-tacr-platform-api"
export WORKLOAD_SERVICE_ACCOUNT="${EXTENSION_NAME}-workload"

az login
az account set --subscription "$SUBSCRIPTION_ID"
az account show \
  --query '{subscription:name,id:id,tenant:tenantId}' \
  --output table

az aks get-credentials \
  --resource-group "$AKS_RESOURCE_GROUP" \
  --name "$AKS_CLUSTER_NAME" \
  --overwrite-existing

kubectl cluster-info
GPU scheduling verification

Confirm the package label and taint contract

Before deployment, verify that the selected node pool carries the label and taint expected by the Marketplace package.

Terminal — GPU node-pool contract
set -euo pipefail

read -r -p "GPU node pool name: " GPU_NODEPOOL_NAME
export GPU_NODEPOOL_NAME

az aks nodepool show \
  --resource-group "$AKS_RESOURCE_GROUP" \
  --cluster-name "$AKS_CLUSTER_NAME" \
  --name "$GPU_NODEPOOL_NAME" \
  --query '{name:name,vmSize:vmSize,count:count,nodeLabels:nodeLabels,nodeTaints:nodeTaints,provisioningState:provisioningState}' \
  --output yaml

kubectl get nodes \
  -l "kubernetes.azure.com/agentpool=$GPU_NODEPOOL_NAME" \
  -L sku

gpu_nodes="$(mktemp)"
kubectl get nodes \
  -l "kubernetes.azure.com/agentpool=$GPU_NODEPOOL_NAME" \
  -o json > "$gpu_nodes"

jq -e '.items | length > 0' "$gpu_nodes" >/dev/null
jq -e 'all(.items[]; .metadata.labels.sku == "gpu")' "$gpu_nodes" >/dev/null
jq -e 'all(.items[]; any(.spec.taints[]?; .key == "sku" and .value == "gpu" and .effect == "NoSchedule"))' "$gpu_nodes" >/dev/null
rm -f "$gpu_nodes"
Marketplace extension deployment

Deploy from the published Azure offer

  1. Open the Azure Marketplace offer and select the intended subscription and deployment resource group.
  2. Select the existing AKS cluster and use the same extension resource name entered in the terminal context. The default is tacr-workflow-mvp.
  3. Use the same release namespace entered in the terminal context, then provide the PostgreSQL host, database and user, Blob Storage resource ID and container names.
  4. Enter the database password and API authentication key only in the protected Marketplace fields.
  5. Use the configuration fields presented by the offer to select the system and GPU node pools, the supported GPU option and the API exposure mode.
  6. Review the Azure deployment summary, then create the extension and wait for reconciliation to complete.
Registry boundary. Use only the container images supplied by the Marketplace offer. Do not replace them with development registry references.
Runtime status

Verify extension reconciliation and AKS workloads

After the portal deployment completes, inspect the extension state and wait for the API deployment to become ready.

Terminal — extension and workload status
set -euo pipefail

if az extension show --name k8s-extension >/dev/null 2>&1; then
  az extension update --name k8s-extension
else
  az extension add --name k8s-extension
fi

az k8s-extension show \
  --cluster-type managedClusters \
  --cluster-name "$AKS_CLUSTER_NAME" \
  --resource-group "$AKS_RESOURCE_GROUP" \
  --name "$EXTENSION_NAME" \
  --query '{name:name,extensionType:extensionType,version:version,provisioningState:provisioningState,releaseNamespace:releaseNamespace}' \
  --output table

kubectl -n "$K8S_NAMESPACE" get deploy,pods,jobs,svc -o wide
kubectl -n "$K8S_NAMESPACE" rollout status \
  deployment/"$API_DEPLOYMENT" \
  --timeout=15m

Confirm GPU resources after extension deployment

The package may install or reconcile the supported GPU stack. Confirm that the selected nodes advertise GPU resources before launching model training.

Terminal — GPU runtime availability
set -euo pipefail

kubectl get nodes \
  -l "kubernetes.azure.com/agentpool=$GPU_NODEPOOL_NAME" \
  -o custom-columns='NAME:.metadata.name,POOL:.metadata.labels.kubernetes\.azure\.com/agentpool,SKU:.metadata.labels.sku,GPU:.status.allocatable.nvidia\.com/gpu,TAINTS:.spec.taints[*].key'

kubectl get daemonset -A \
  -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,DESIRED:.status.desiredNumberScheduled,READY:.status.numberReady' \
  | grep -Ei 'nvidia|gpu' || true
Azure Workload Identity verification

Confirm the runtime service-account binding

The Marketplace lifecycle binds the application service account to a buyer-controlled Azure identity. Inspect the service account and pod binding without printing credentials.

Terminal — workload identity binding
set -euo pipefail

kubectl -n "$K8S_NAMESPACE" get serviceaccount "$WORKLOAD_SERVICE_ACCOUNT" \
  -o json | jq '{name:.metadata.name,labels:.metadata.labels,annotations:.metadata.annotations}'

kubectl -n "$K8S_NAMESPACE" get deployment "$API_DEPLOYMENT" \
  -o jsonpath='{.spec.template.spec.serviceAccountName}{"\n"}'

kubectl -n "$K8S_NAMESPACE" get pods \
  -l app.kubernetes.io/component=api \
  -o custom-columns='NAME:.metadata.name,SERVICE_ACCOUNT:.spec.serviceAccountName,NODE:.spec.nodeName'
Health and readiness verification

Verify the internal service on port 8080

The service remains internal unless the buyer explicitly configures ingress. Use a local port-forward to check /healthz and /readyz.

Terminal — private runtime health
set -euo pipefail

export LOCAL_PORT="$(
  python3 - <<'PYPORT'
import socket
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as sock:
    sock.bind(("127.0.0.1", 0))
    print(sock.getsockname()[1])
PYPORT
)"

kubectl -n "$K8S_NAMESPACE" port-forward \
  service/"$API_SERVICE" \
  "$LOCAL_PORT:8080" > "${TMPDIR:-/tmp}/tacr-port-forward.log" 2>&1 &
PORT_FORWARD_PID=$!
trap 'kill "$PORT_FORWARD_PID" 2>/dev/null || true' EXIT

for attempt in $(seq 1 30); do
  if curl -fsS "http://127.0.0.1:$LOCAL_PORT/healthz" >/dev/null; then
    break
  fi
  sleep 2
done

curl -fsS "http://127.0.0.1:$LOCAL_PORT/healthz"
curl -fsS "http://127.0.0.1:$LOCAL_PORT/readyz"
Governed model lifecycle

From executable workflow topology to governed inference

The approved customer workflow topology is incorporated into model adaptation, producing a policy-bound model artifact with a structurally bounded workflow action space. The artifact must complete mandatory qualification before it can be deployed for governed inference.

1

Policy and topology

Customer-defined states, admissible transitions and evidence requirements become executable workflow topology.

2

Policy-constrained model adaptation

The managed GPU job creates an artifact specific to the approved workflow inside the buyer environment.

3

Qualification before deployment

A trained artifact cannot create a production inference deployment until the complete policy-bound model is qualified.

4

Governed inference

The qualified artifact performs inference within the bounded action space. Governance is embedded in model adaptation, not applied after generation.

API use. Use the API contract and examples delivered with the installed offer. Do not invent request bodies or rely on payloads from another release.
Operations

Update or remove the Kubernetes application extension

1

Update to a published extension version

Use only a version published for the Marketplace offer. Azure reconciles the managed extension after the update.

Terminal — extension update
set -euo pipefail

read -r -p "Published extension version to install: " TARGET_EXTENSION_VERSION

az k8s-extension update \
  --cluster-type managedClusters \
  --cluster-name "$AKS_CLUSTER_NAME" \
  --resource-group "$AKS_RESOURCE_GROUP" \
  --name "$EXTENSION_NAME" \
  --version "$TARGET_EXTENSION_VERSION" \
  --auto-upgrade-minor-version false

az k8s-extension show \
  --cluster-type managedClusters \
  --cluster-name "$AKS_CLUSTER_NAME" \
  --resource-group "$AKS_RESOURCE_GROUP" \
  --name "$EXTENSION_NAME" \
  --query '{version:version,provisioningState:provisioningState}' \
  --output table
2

Remove the extension

This removes extension-managed Kubernetes workloads. PostgreSQL, Blob Storage, identities, networking and other buyer resources are not deleted.

Terminal — confirmed extension removal
set -euo pipefail

read -r -p "Type REMOVE to delete the Kubernetes application extension: " CONFIRM
if [ "$CONFIRM" != "REMOVE" ]; then
  echo "Removal cancelled."
  exit 1
fi

az k8s-extension delete \
  --cluster-type managedClusters \
  --cluster-name "$AKS_CLUSTER_NAME" \
  --resource-group "$AKS_RESOURCE_GROUP" \
  --name "$EXTENSION_NAME"

kubectl -n "$K8S_NAMESPACE" get all
Security boundary

Controls retained by the buyer

ControlBuyer responsibilityRuntime behavior
IdentityManaged identities, federated credentials, Azure RBAC and Kubernetes RBACWorkloads use the bound Azure Workload Identity
SecretsProtected Marketplace settings, Key Vault integration where selected and Kubernetes secret policySensitive values are not required in public Helm values
NetworkingAKS API access, private endpoints, NSGs, DNS, certificates and ingressThe Kubernetes service remains internal by default
DataPolicies, workflow state, training inputs, model artifacts and operational recordsPostgreSQL and Blob Storage remain in the buyer subscription
Troubleshooting and support

Escalate with sanitized operational context

For product deployment issues, provide the offer version, Azure Region, AKS version, extension provisioning state, failing command, sanitized Kubernetes events and UTC timestamps. Remove subscription IDs, tenant IDs, identity client IDs, private endpoints, tokens, passwords, request data and customer information before sharing logs.

Use Azure Support for underlying Azure service or Marketplace entitlement issues. Contact Golem Technologies for extension behavior, training, qualification, inference or application support.

Request technical support
✓Command copied to clipboard.