Deploy on GCP GKE

This guide covers deploying the Hiya Voice Verification engine on Google Kubernetes Engine (GKE). It builds on the generic Kubernetes guide with GKE-specific configuration.

Prerequisites

• A GKE cluster (Standard or Autopilot) with kubectl configured
• Container image pulled and authenticated — see Getting the Container Image
• A valid API_KEY from your Hiya account team
• gcloud CLI installed

Recommended Machine Types

We recommend machines based on Intel Emerald Rapids processors for optimal performance:

Machine Series	Category	Notes
N4	General-purpose	Up to 80 vCPUs, DDR5
C4	Compute-optimized	Emerald Rapids for sizes up to 96 vCPUs
M4	Memory-optimized	Up to 224 vCPUs, up to 3 TB RAM

Ensure your node pool instances have at least 8 GB of available RAM per pod.

GKE Standard vs Autopilot

	Standard	Autopilot
Node management	You manage node pools	Google manages nodes
Instance type control	Full control	Requests via resource limits
tmpfs (emptyDir Memory)	Supported	Supported (counts against pod memory)
Best for	Maximum control	Simpler operations

Both modes work with the Hiya engine. If using Autopilot, ensure your pod resource requests account for the 4 GB emptyDir memory volume.

Step 1 — Authenticate with the Registry

Since you're already on GCP, you can use Workload Identity as an alternative to image pull secrets. However, since the image is hosted on a Hiya-managed project, the simplest approach is still the pull secret method.

Option A — Image Pull Secret (recommended)

kubectl create secret docker-registry hiya-registry \
  --docker-server=europe-docker.pkg.dev \
  --docker-username=_json_key \
  --docker-password="$(cat key.json)"

Option B — gcloud Credential Helper

If you prefer to configure registry access at the node level:

gcloud auth activate-service-account --key-file=key.json
gcloud auth configure-docker europe-docker.pkg.dev

This works for Standard clusters where you control the node configuration. For Autopilot, use Option A.

Step 2 — Create Secrets and Deploy

Store the API key and apply the deployment:

kubectl create secret generic hiya-engine-config \
  --from-literal=api-key=<your-api-key>

Apply the Deployment and Service manifests from the Kubernetes guide. No GKE-specific changes are needed.

Step 3 — Expose via Internal Load Balancer (Optional)

For clients outside the cluster, use a GKE internal load balancer. Since the engine uses gRPC (HTTP/2), use a TCP-mode load balancer:

# hiya-ilb-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: hiya-voice-verification-ilb
  annotations:
    networking.gke.io/load-balancer-type: Internal
spec:
  type: LoadBalancer
  selector:
    app: hiya-voice-verification
  ports:
    - name: grpc
      protocol: TCP
      port: 8080
      targetPort: 8080
    - name: ws
      protocol: TCP
      port: 8081
      targetPort: 8081

Network Configuration

GKE nodes need outbound access to:

Destination	Port	Protocol	Purpose
europe-docker.pkg.dev	443	HTTPS	Image pulls (typically already allowed on GCP)
api.hiya.com	443	HTTPS	License verification and billing

For private clusters with no external IP on nodes, ensure Cloud NAT is configured for outbound internet access.

Scaling

Use the Horizontal Pod Autoscaler or GKE's Cluster Autoscaler for automatic scaling. The engine is stateless — scaling is as simple as increasing replicas.

kubectl autoscale deployment hiya-voice-verification \
  --cpu-percent=50 \
  --min=1 \
  --max=10

For Standard clusters, the Cluster Autoscaler will provision new nodes when pods are pending.