Google Cloud / GKE · Deployment & implementation guide

Bounded Agentic AI Workflow Engine for GKE

A deployment and operations guide for a customer-hosted runtime inside a buyer-controlled Google Cloud project, private GKE environment, VPC and data boundary.

DeliveryTerraform Kubernetes path or authorized Helm release
RuntimeBuyer-owned private GKE environment
Default accessInternal Kubernetes service
IdentityWorkload Identity Federation for GKE
StateCloud SQL and Cloud Storage
GPU lifecycleDedicated autoscaled training and inference pool
Overview

Bounded agentic workflows inside customer-controlled Google Cloud

The Bounded Agentic AI Workflow Engine is customer-hosted execution infrastructure for enterprise workflows that require deterministic admissibility, controlled model lifecycle, traceability and governed inference.

  • AI-assisted outputs remain candidate actions until validated against deterministic workflow constraints.
  • Policy, lifecycle orchestration, qualification, inference and evidence services operate inside the customer’s Google Cloud boundary.
  • Workflow state, model artifacts, prompts, traces and governance metadata remain under buyer-controlled identity, network and retention policies.
  • The runtime is designed for regulated operations where an AI proposal must not become an executable action without policy-bound validation.
Publication status. This page describes the Google Cloud Marketplace publication path and technical-validation model. It does not represent that a public Google Cloud Marketplace listing is already available.
Architectural Overview

Sovereign Enterprise Deployment

The Bounded Agentic AI Workflow Engine is delivered as a secure, containerized application for customer-controlled GKE private clusters. The default architecture is single-tenant and customer-hosted. Model weights, prompts, workflow policies, traces, and governance metadata remain strictly inside the customer’s Google Cloud project and VPC boundary.

Tenant boundaries and priced Google Cloud resources
Tenant boundaries and priced Google Cloud resources for the GKE marketplace architecture
Tenant boundaries and priced Google Cloud resources.

Customer-hosted operating boundary

Customer-hosted runtime

Private-by-default operating model

Application services run on buyer-operated GKE, use internal Kubernetes networking by default and connect only to buyer-approved Google Cloud services and external endpoints.

Buyer-controlled sovereignty

Identity, data and retention remain local

The buyer retains control of IAM, networking, encryption, storage location, logging, monitoring, retention and operational access throughout the workflow and model lifecycle.

Deterministic execution boundary. The runtime evaluates AI-assisted outputs, tool-use proposals and workflow actions against approved business-process rules before downstream execution. An AI proposal remains a candidate action until it is admitted by the executable workflow topology.
Customer-hosted architecture

GKE-native architecture for governed AI workflow execution

The deployment separates delivery, Kubernetes execution, workload identity, data services and observability while keeping the operating boundary inside the buyer’s Google Cloud project and VPC.

Scope and landing-zone assumptions

Application lifecycle, not an entire Google Cloud landing zone

The authorized deployment binds the runtime to buyer-supplied infrastructure. Project governance and foundational cloud controls remain the buyer’s responsibility.

Installed by the release

Namespaced runtime and lifecycle

Application workloads, services, policies, database migration, model-job orchestration, qualification and governed inference bindings.

Prepared by the buyer

Google Cloud foundation

Project, VPC, GKE, node pools, Cloud SQL, Cloud Storage, Pub/Sub, IAM, DNS, certificates, ingress policy, egress policy and operational controls.

Private by default. The application service remains internal unless the buyer explicitly enables an approved ingress path with authentication, certificates, DNS and network restrictions.
Prerequisites

Prepare the Google Cloud landing zone

  • Buyer-controlled Google Cloud project with billing, organization policy and IAM governance configured.
  • Private GKE environment with a system node pool and a separately scheduled GPU node pool.
  • Artifact Registry access for the authorized container release.
  • Cloud SQL for PostgreSQL reachable through the buyer-approved private connectivity pattern.
  • Cloud Storage, Pub/Sub and Secret Manager resources governed by least-privilege IAM.
  • Workload Identity Federation for GKE enabled for application service accounts.
  • Cloud Logging and Cloud Monitoring configured for the buyer’s operational and retention requirements.
  • Approved access to the selected base-model repository and any required licence acceptance.
Terminal — operator prerequisites
set -euo pipefail

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

gcloud version | sed -n '1,6p'
kubectl version --client
helm version --short
terraform version | sed -n '1,2p'
Project identity and cluster access

Connect to the intended buyer project and GKE environment

Set only buyer-owned identifiers. Keep the same shell open so the exported values remain available to later checks.

Terminal — Google Cloud and GKE context
set -euo pipefail

read -r -p "Google Cloud project ID: " GCP_PROJECT_ID
read -r -p "GKE region or zone: " GKE_LOCATION
read -r -p "GKE cluster name: " GKE_CLUSTER_NAME
read -r -p "Kubernetes namespace [tacr-system]: " K8S_NAMESPACE
K8S_NAMESPACE="${K8S_NAMESPACE:-tacr-system}"

export GCP_PROJECT_ID GKE_LOCATION GKE_CLUSTER_NAME K8S_NAMESPACE

gcloud auth login
gcloud config set project "$GCP_PROJECT_ID"

# Terraform on a local operator workstation uses Application Default Credentials.
gcloud auth application-default login
gcloud auth application-default set-quota-project "$GCP_PROJECT_ID"

gcloud auth list --filter=status:ACTIVE --format='table(account,status)'

gcloud container clusters get-credentials "$GKE_CLUSTER_NAME" \
  --location "$GKE_LOCATION" \
  --project "$GCP_PROJECT_ID"

gcloud container clusters describe "$GKE_CLUSTER_NAME" \
  --location "$GKE_LOCATION" \
  --project "$GCP_PROJECT_ID" \
  --format='yaml(name,location,currentMasterVersion,privateClusterConfig,workloadIdentityConfig,loggingConfig,monitoringConfig)'

kubectl cluster-info
kubectl auth can-i get pods --all-namespaces
Cloud Shell. Google Cloud Shell normally provides an authenticated environment. When organizational policy already supplies valid Application Default Credentials, the interactive ADC login step may be skipped; verify the active project and quota project before running Terraform.
Terminal — required Google Cloud services
set -euo pipefail

gcloud services list \
  --enabled \
  --project "$GCP_PROJECT_ID" \
  --filter='NAME:(container.googleapis.com artifactregistry.googleapis.com sqladmin.googleapis.com storage.googleapis.com pubsub.googleapis.com secretmanager.googleapis.com logging.googleapis.com monitoring.googleapis.com)' \
  --format='table(NAME,TITLE)'
Authorized release

Use only the buyer-authorized GKE release

The Google Cloud publication path uses an authorized Terraform Kubernetes package and Helm lifecycle. Do not substitute development images, local charts or unapproved registry references.

Terraform Kubernetes path

Validates buyer inputs, binds the release to the selected project and cluster, and reconciles the application through declared infrastructure state.

Authorized Helm path

Supports controlled assisted deployment when a buyer receives an approved chart and values contract outside the public listing flow.

Artifact Registry boundary

Container image references must come from the authorized release metadata. Development repositories are not a deployment source.

No secret material in values

Deployment configuration references buyer-controlled secret objects. Secret values stay outside public Terraform inputs and Helm values.

Terminal — inspect an authorized Terraform module
set -euo pipefail

read -r -p "Path to authorized Terraform module directory: " MODULE_DIR
read -r -p "Path to buyer-approved variables file: " TFVARS_FILE

MODULE_DIR="$(cd "$MODULE_DIR" && pwd)"
TFVARS_FILE="$(cd "$(dirname "$TFVARS_FILE")" && pwd)/$(basename "$TFVARS_FILE")"

test -d "$MODULE_DIR"
test -f "$TFVARS_FILE"

terraform -chdir="$MODULE_DIR" fmt -check -recursive
terraform -chdir="$MODULE_DIR" init
terraform -chdir="$MODULE_DIR" validate
terraform -chdir="$MODULE_DIR" plan \
  -var-file="$TFVARS_FILE" \
  -out=deployment.tfplan

terraform -chdir="$MODULE_DIR" show -no-color deployment.tfplan
Review before apply. Confirm the target project, GKE context, namespace, image references, IAM bindings, database endpoint, storage resources, Pub/Sub resources, network posture and absence of secret values in the plan.
Identity and protected values

Bind workloads without application service-account key files

Workload Identity Federation for GKE maps the Kubernetes service account to a buyer-controlled Google service account. Secret values remain in the buyer’s approved secret-handling process and are referenced by the runtime rather than embedded in deployment files.

Terminal — Workload Identity binding
set -euo pipefail

read -r -p "Google Cloud service account name: " GCP_SERVICE_ACCOUNT
read -r -p "Runtime Kubernetes service account: " WORKLOAD_SERVICE_ACCOUNT
export GCP_SERVICE_ACCOUNT WORKLOAD_SERVICE_ACCOUNT

GCP_SERVICE_ACCOUNT_EMAIL="${GCP_SERVICE_ACCOUNT}@${GCP_PROJECT_ID}.iam.gserviceaccount.com"
export GCP_SERVICE_ACCOUNT_EMAIL

gcloud iam service-accounts describe "$GCP_SERVICE_ACCOUNT_EMAIL" \
  --project "$GCP_PROJECT_ID" \
  --format='value(email)'

kubectl create namespace "$K8S_NAMESPACE" \
  --dry-run=client -o yaml | kubectl apply -f -

kubectl -n "$K8S_NAMESPACE" create serviceaccount "$WORKLOAD_SERVICE_ACCOUNT" \
  --dry-run=client -o yaml | kubectl apply -f -

# Bind the Kubernetes Service Account to the Google Cloud Service Account.
gcloud iam service-accounts add-iam-policy-binding \
  "$GCP_SERVICE_ACCOUNT_EMAIL" \
  --project "$GCP_PROJECT_ID" \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:${GCP_PROJECT_ID}.svc.id.goog[${K8S_NAMESPACE}/${WORKLOAD_SERVICE_ACCOUNT}]"

# Annotate the Kubernetes Service Account with the Google Cloud identity.
kubectl annotate serviceaccount "$WORKLOAD_SERVICE_ACCOUNT" \
  --namespace "$K8S_NAMESPACE" \
  iam.gke.io/gcp-service-account="$GCP_SERVICE_ACCOUNT_EMAIL" \
  --overwrite
Terminal — Workload Identity verification
set -euo pipefail

EXPECTED_MEMBER="serviceAccount:${GCP_PROJECT_ID}.svc.id.goog[${K8S_NAMESPACE}/${WORKLOAD_SERVICE_ACCOUNT}]"

gcloud iam service-accounts get-iam-policy \
  "$GCP_SERVICE_ACCOUNT_EMAIL" \
  --project "$GCP_PROJECT_ID" \
  --format=json \
  | jq -e --arg member "$EXPECTED_MEMBER" '
      any(.bindings[]?;
        .role == "roles/iam.workloadIdentityUser" and
        any(.members[]?; . == $member)
      )
    ' >/dev/null

echo "Workload Identity IAM binding verified."

kubectl -n "$K8S_NAMESPACE" get serviceaccount "$WORKLOAD_SERVICE_ACCOUNT" \
  -o json | jq '{
    name: .metadata.name,
    namespace: .metadata.namespace,
    googleServiceAccount: .metadata.annotations["iam.gke.io/gcp-service-account"]
  }'

kubectl -n "$K8S_NAMESPACE" get pods \
  -o custom-columns='NAME:.metadata.name,SERVICE_ACCOUNT:.spec.serviceAccountName,NODE:.spec.nodeName'
  • Do not place passwords, API credentials or model-repository credentials in public configuration, shell history, tickets or documentation.
  • Do not use long-lived Google service-account JSON key files for the application runtime.
  • Grant the workload identity only the Cloud SQL, Cloud Storage, Pub/Sub and operational permissions required by the deployed release.
  • Use customer-defined rotation, audit and retention controls for Secret Manager and Kubernetes secret synchronization.
GPU scheduling contract

Keep training and inference on explicit GPU capacity

System services and accelerator workloads use separate scheduling contracts. The buyer selects supported machine and accelerator profiles, verifies regional quota and capacity, and controls whether GPU nodes may autoscale from zero.

Terminal — node pools, labels, taints and GPUs
set -euo pipefail

kubectl get nodes \
  -L cloud.google.com/gke-nodepool,tacr.golem.tech/node-pool

kubectl get nodes \
  -l tacr.golem.tech/node-pool=gpu \
  -o custom-columns='NAME:.metadata.name,POOL:.metadata.labels.cloud\.google\.com/gke-nodepool,ROLE:.metadata.labels.tacr\.golem\.tech/node-pool,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
Scale-to-zero is valid. A GPU node pool may have no active nodes until an authorized training or inference workload requests accelerator capacity. Validate labels, taints, autoscaling limits and quota before opening the GPU workload window.
Installation & Configuration

Google Cloud Marketplace publication path

Post-publication buyer flow. This section describes the intended deployment path after publication. It does not claim that the public Google Cloud Marketplace listing is currently available.

Following publication, the authorized product release will deploy from Google Cloud Marketplace into the buyer-controlled GKE environment. Containers are delivered through Artifact Registry. Runtime execution occurs inside the private cluster, with AI workloads running securely on dedicated GPU node pools.

Controlled Terraform and Helm installation path

Terminal — reviewed Terraform apply
set -euo pipefail

read -r -p "Type APPLY to execute the reviewed plan: " CONFIRM
if [ "$CONFIRM" != "APPLY" ]; then
  echo "Apply cancelled."
  exit 1
fi

terraform -chdir="$MODULE_DIR" apply deployment.tfplan
rm -f "$MODULE_DIR/deployment.tfplan"

kubectl -n "$K8S_NAMESPACE" get deploy,pods,jobs,svc -o wide
Terminal — authorized Helm installation
set -euo pipefail

read -r -p "Path to authorized Helm chart archive: " GKE_CHART
read -r -p "Path to buyer-approved Helm values file: " GKE_VALUES
read -r -p "Helm release name [tacr]: " HELM_RELEASE
HELM_RELEASE="${HELM_RELEASE:-tacr}"

export GKE_CHART GKE_VALUES HELM_RELEASE

test -f "$GKE_CHART"
test -f "$GKE_VALUES"

helm show chart "$GKE_CHART"
helm lint "$GKE_CHART" -f "$GKE_VALUES"

helm upgrade --install "$HELM_RELEASE" "$GKE_CHART" \
  --namespace "$K8S_NAMESPACE" \
  --create-namespace \
  -f "$GKE_VALUES" \
  --atomic \
  --timeout 20m \
  --history-max 10
Health and readiness

Verify the internal runtime before exposing any ingress

The default service is private. Use a local port-forward to confirm application health and readiness without creating a public endpoint.

Terminal — private runtime health
set -euo pipefail

read -r -p "Runtime API deployment name: " API_DEPLOYMENT
read -r -p "Runtime API service name: " API_SERVICE

kubectl -n "$K8S_NAMESPACE" rollout status \
  deployment/"$API_DEPLOYMENT" \
  --timeout=15m

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}/gke-runtime-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"
Lifecycle & Process Flow

Managed Lifecycle and Bounded Execution

Our neuro-symbolic engine acts as a deterministic policy enforcement layer between an upstream AI proposal and downstream execution. It evaluates AI-assisted outputs, tool-use proposals, and workflow actions against approved business-process rules before execution.

Policy compilation, fine-tuning, and governed inference flow
Policy compilation, fine-tuning, and governed inference flow
Policy compilation, fine-tuning, and governed inference flow.
End-to-end sequence diagram for policy submission and model invocation
End-to-end sequence diagram for policy submission and model invocation
End-to-end sequence diagram for policy submission and model invocation.

Operational lifecycle controls

The approved workflow topology is incorporated into model adaptation, producing a policy-bound artifact with a structurally bounded workflow action space. Qualification is mandatory before governed inference deployment.

Policy and topology

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

Policy-constrained adaptation

A managed GPU workload creates an artifact specific to the approved workflow inside the buyer environment.

Mandatory qualification

The complete policy-bound artifact must satisfy the release qualification contract before it can progress to inference.

Governed inference

The qualified artifact performs inference within the bounded action space, with traceable policy and model lineage.

Not post-generation checking. Governance is incorporated into the model and workflow lifecycle so inadmissible workflow actions are structurally constrained before operational execution.
Operations

Inspect, update, roll back or remove the release

Use the same authorized package discipline for every lifecycle change. Buyer-owned Cloud SQL, Cloud Storage, Pub/Sub, IAM, networking, DNS and certificates remain outside the application release unless the reviewed infrastructure plan explicitly states otherwise.

Terminal — release status
set -euo pipefail

read -r -p "Helm release name [tacr]: " HELM_RELEASE
HELM_RELEASE="${HELM_RELEASE:-tacr}"
export HELM_RELEASE

helm -n "$K8S_NAMESPACE" status "$HELM_RELEASE"
helm -n "$K8S_NAMESPACE" history "$HELM_RELEASE"
kubectl -n "$K8S_NAMESPACE" get deploy,pods,jobs,svc,ingress -o wide
Terminal — controlled Helm rollback
set -euo pipefail

helm -n "$K8S_NAMESPACE" history "$HELM_RELEASE"
read -r -p "Revision to restore: " REVISION

helm -n "$K8S_NAMESPACE" rollback "$HELM_RELEASE" "$REVISION" \
  --wait \
  --timeout 20m

kubectl -n "$K8S_NAMESPACE" get deploy,pods,svc -o wide
Removal path. Use the reviewed Terraform lifecycle for a Terraform-managed release. The command below applies only to an explicitly Helm-managed assisted deployment.
Terminal — confirmed Helm release removal
set -euo pipefail

read -r -p "Type UNINSTALL to remove the namespaced application release: " CONFIRM
if [ "$CONFIRM" != "UNINSTALL" ]; then
  echo "Removal cancelled."
  exit 1
fi

helm -n "$K8S_NAMESPACE" uninstall "$HELM_RELEASE"
kubectl -n "$K8S_NAMESPACE" get all
Security boundary

Controls retained by the buyer

ControlBuyer responsibilityRuntime behavior
IdentityGoogle Cloud IAM, Workload Identity Federation, Kubernetes RBAC and least-privilege service accounts.Application workloads use the bound identity without application service-account key files.
SecretsSecret Manager policy, rotation, audit, access approval and Kubernetes synchronization controls.Public Terraform inputs and Helm values reference secret objects rather than carrying secret values.
NetworkingVPC, GKE control-plane access, private service connectivity, egress, DNS, certificates and ingress policy.The application service remains internal by default and no public ingress is required.
DataPolicies, workflow state, training inputs, model artifacts, traces and retained operational records.Cloud SQL and Cloud Storage remain inside the buyer project and data-governance boundary.
EventsPub/Sub topics, subscriptions, retention, dead-letter policy and service-account permissions.Lifecycle and workflow events use buyer-controlled messaging resources.
ObservabilityCloud Logging, Cloud Monitoring, alerting, export, retention and security operations integration.Runtime logs and metrics remain subject to buyer-defined operational policy.
AcceleratorsGPU quota, regional capacity, machine profile, autoscaling bounds and cost controls.Training and inference workloads require explicit GPU scheduling and cannot silently move to system nodes.
Troubleshooting and support

Escalate with sanitized operational context

For deployment assistance, provide the authorized release identifier, Google Cloud region, GKE version, failing command, sanitized Kubernetes events and UTC timestamps. Remove project numbers, private endpoints, credentials, request data and customer information before sharing diagnostics.

  • Use Google Cloud support channels for project billing, quota, GKE, Cloud SQL, Artifact Registry and platform-service issues.
  • Contact Golem Technologies for application lifecycle, model adaptation, qualification, governed inference or release-package behavior.
  • Never attach raw secret objects, complete environment dumps or unsanitized customer payloads to a support request.
Continue

Continue with the GKE deployment guide

Review the buyer-controlled architecture, Workload Identity binding, bounded model lifecycle and controlled installation path on this page, or discuss the deployment of one governed enterprise workflow.

Command copied to clipboard.
Expanded diagram