India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Google Kubernetes Engine (GKE) Autopilot & Standard Services
Google Kubernetes Engine (GKE) is Google Cloud's managed Kubernetes service, offered in Autopilot mode, where Google manages nodes and you pay per pod, and Standard mode, where you control node pools. NTSPL designs GKE clusters and fleets with Artifact Registry, Binary Authorization, Config Sync GitOps and Gateway API so Indian SaaS and digital teams ship containers safely at scale.
Google Cloud services in scope
The Problem GKE Autopilot and GKE Standard Solve
Most Kubernetes pain on Google Cloud is not Kubernetes itself but what grew around it: Standard clusters with eight hand-tuned node pools at 30% utilization, pods with no resource requests so the scheduler packs them blindly, images pulled from Docker Hub with no signature check, and a different kubectl-applied state in each environment. When match-day or month-end traffic arrives, the cluster autoscaler waits minutes for nodes while HPA has already asked for pods. GKE gives you the managed control plane; the engineering is in requests, autoscaling layers, supply-chain controls and configuration drift.
NTSPL decides Autopilot or Standard per cluster, not per company. Autopilot is our default for application workloads because per-pod billing punishes over-requesting directly and Google handles node upgrades and hardening. Standard remains for GPU-heavy, DaemonSet-heavy or kernel-tuned workloads. Around either mode we build a fleet: images in Artifact Registry with vulnerability scanning, Binary Authorization attestations from Cloud Build, Config Sync from Git for every cluster, and Gateway API replacing ad hoc Ingress objects.
When GKE Is the Right Platform for Your Containers (and When Cloud Run Is Simpler)
Signals that point to kubernetes on Google Cloud
- You run more than 15 containerized services and deployment coordination across teams is now the bottleneck.
- Node utilization on existing clusters averages below 40% while teams still request new node pools.
- Pods take more than three minutes to become ready during traffic surges because nodes must be provisioned first.
- A security review found images running in production that were never scanned or that came straight from public registries.
- Self-managed Kubernetes upgrades are more than two minor versions behind because nobody owns the upgrade runbook.
When a different approach is better
- Fewer than five stateless HTTP services with spiky traffic usually run more cheaply and simply on Cloud Run, with no cluster to operate.
- A single monolithic VM application with no plan to containerize belongs in a Compute Engine MIG until refactoring is funded.
- Large stateful databases are better on Cloud SQL, AlloyDB or Spanner than as StatefulSets you must back up and fail over yourself.
GKE Building Blocks: Autopilot, Standard, Artifact Registry, Binary Authorization, Config Sync and Gateway API
| Service | Role in the architecture | Choose it when |
|---|---|---|
| GKE Autopilot | Fully managed GKE mode in which Google provisions, scales, patches and secures nodes, and billing follows the CPU, memory and ephemeral storage that pods request. | Teams want Kubernetes APIs without operating node pools, and workloads do not need privileged access or custom kernels. |
| GKE Standard | GKE mode with full control over node pools, machine types, GPUs, node images and system settings, billed per node VM. | You need specific GPU or TPU node layouts, privileged DaemonSets, kernel parameters or very high pod density per node. |
| Artifact Registry | Regional or multi-regional registry for container images and language packages, with vulnerability scanning through Artifact Analysis and remote repositories that cache upstream registries. | Images currently come from public registries directly or from a self-hosted registry with no scanning. |
| Binary Authorization | Admission control that permits only images carrying required attestations, such as a passing build and vulnerability scan, to run on GKE. | Auditors or regulators ask how you prove only reviewed, scanned images reach production. |
| Config Sync and fleets | GitOps reconciliation that keeps namespaces, RBAC, network policies and workloads identical across a fleet of registered clusters, with Policy Controller enforcing constraints. | You run three or more clusters and configuration drift between them has already caused an incident. |
| GKE Gateway API | Kubernetes Gateway API implementation backed by Cloud Load Balancing, supporting role separation between platform and app teams, traffic splitting and multi-cluster gateways. | Ingress annotations have become unmanageable or you need weighted canaries and cross-cluster routing. |
Regional GKE Autopilot fleet with signed-image delivery
Regional GKE Autopilot fleet with signed-image delivery
Users reach services through a Gateway API-managed global external Application Load Balancer that routes by host and path to Services on a regional Autopilot cluster in asia-south1, with a second cluster in asia-south2 for failover. Code merged to Git triggers Cloud Build, which pushes images to Artifact Registry and creates attestations that Binary Authorization verifies at admission, while Config Sync reconciles cluster configuration from a separate repository.
Select any component
Regional GKE Autopilot fleet with signed-image delivery: click any of its 10 components to see its role and the design choice NTSPL makes for it, or trace the 6-step primary path.
GKE Engineering Decisions: Cluster Mode, Autoscaling Layers, Tenancy and Release Channels
Autopilot or Standard per cluster
Autopilot suits clusters where workloads are standard Deployments and the team lacks dedicated node operators; billing per requested vCPU and memory makes waste visible to developers. Choose Standard when you need GPUs in custom node layouts, privileged DaemonSets such as some security agents, kernel tuning, or more than about 110 small pods per node. Mixed estates are normal: Autopilot for applications, Standard for ML inference or legacy agents.
Autoscaling layers and surge readiness
HPA reacts within 15-30 seconds, but new capacity takes longer to provision, so surges see pending pods. For predictable peaks we pre-scale with scheduled HPA minimums 30 minutes before events, and in Standard we keep a low-priority placeholder deployment that is evicted instantly when real pods arrive. Custom metrics from Managed Service for Prometheus, such as requests per pod or queue lag, scale web and worker tiers far more accurately than CPU alone.
Tenancy model for SaaS
Namespace-per-tenant on shared clusters works for up to a few hundred tenants with similar trust levels, enforced through ResourceQuotas, NetworkPolicies and Policy Controller. Tenants with contractual isolation, such as regulated enterprise customers, get dedicated node pools in Standard or a separate cluster in the fleet. Cluster-per-tenant above roughly 20 tenants becomes an upgrade and cost burden unless fleet tooling like Config Sync is already mature.
Release channel and upgrade policy
Production clusters enrol in the Regular or Stable channel, with non-production one channel ahead so new minor versions are exercised for two to four weeks before production sees them. Maintenance windows are set to low-traffic hours IST, typically 1 am to 5 am, and maintenance exclusions cover festive sales, financial year-end or match days. PodDisruptionBudgets on every Deployment make surge upgrades safe.
Ingress to Gateway API migration
We migrate one host at a time: create a Gateway owned by the platform namespace, recreate each Ingress as an HTTPRoute in the app namespace, compare responses with traffic mirrored, then move DNS. Gateway API gives weighted traffic splitting for canaries without a service mesh, and role separation so app teams cannot change TLS or Cloud Armor. Multi-cluster Gateway is added only once both regional clusters run identical Config Sync state.
How NTSPL Builds a Production GKE Fleet with GitOps and Signed Images
Workload readiness and request profiling
Measure actual CPU and memory per container for two weeks, set requests and limits from P95 usage, and flag workloads that need privileged access or GPUs.
Fleet and cluster provisioning
Create regional Autopilot or Standard clusters in asia-south1 and asia-south2 with private nodes, Workload Identity Federation and release channels, registered to one fleet.
Supply-chain pipeline
Move images into Artifact Registry, wire Cloud Build scanning and KMS-signed attestations, and enable Binary Authorization in dry-run before enforcing.
Config Sync and policy baseline
Bootstrap Config Sync from Git, apply namespace, quota and network-policy templates, and roll out Policy Controller constraints in audit mode first.
Gateway API and traffic migration
Stand up the Gateway, migrate Ingress objects to HTTPRoutes host by host, and shift DNS with weighted canaries.
Surge and upgrade rehearsal
Load-test at 3-5x peak, tune HPA and pre-scaling, and run one minor-version upgrade end to end before go-live.
What you receive
Hardening GKE: Workload Identity Federation, Binary Authorization and Policy Controller
GKE threats concentrate on the software supply chain and workload identity: unsigned images, pods running as root with host mounts, service-account keys mounted as secrets, and a flat pod network where one compromised service reaches every database. NTSPL enforces Binary Authorization on production namespaces, uses Workload Identity Federation for GKE so pods get short-lived Google credentials, applies NetworkPolicies through GKE Dataplane V2, and blocks privileged pods with Policy Controller.
- Binary Authorization requiring build and vulnerability-scan attestations before admission
- Workload Identity Federation for GKE to replace exported service-account keys
- Private clusters with authorised networks or DNS-based control plane access restricted by IAM
- Policy Controller constraints blocking privileged containers, hostPath mounts and missing resource requests
- GKE Dataplane V2 NetworkPolicies with default-deny per namespace and network policy logging
GKE Pricing Levers: Autopilot Pod Requests, Spot Pods, Bin-Packing and Committed Use
GKE charges a cluster management fee of USD 0.10 per cluster per hour, with a monthly free-tier credit that covers one zonal or Autopilot cluster per billing account. Autopilot then bills pod resource requests per second, so over-requesting costs money directly; Standard bills underlying Compute Engine node VMs regardless of how well pods are packed. Load balancers, persistent disks and egress are billed separately.
- Rightsize pod requests from VPA recommendations, which typically reduces Autopilot spend by 20-35%
- Spot Pods on Autopilot or Spot node pools on Standard for fault-tolerant workers and batch jobs
- Committed use discounts for steady Autopilot or node-pool baselines after two months of data
- Scale non-production Deployments to zero outside working hours using scheduled CronJobs
- Consolidate small clusters into namespaces within a fleet to cut management fees and idle capacity
GKE Autopilot vs GKE Standard vs Cloud Run: which should run our containers?
Compare on control, billing and operations. Cloud Run is simplest: deploy a container, get an HTTPS endpoint, scale to zero, pay per request or instance time, with no Kubernetes objects to manage; it suits stateless services and jobs without sidecar-heavy or custom networking needs. GKE Autopilot gives full Kubernetes APIs, StatefulSets, operators, Gateway API and fleet GitOps, with Google running nodes and billing per pod request; it suits platforms with many services and shared policy. GKE Standard adds node-level control for GPUs, privileged agents and custom kernels, but you own node sizing, bin-packing and upgrade timing. Our default is Cloud Run for edge APIs, Autopilot for the core platform, and Standard only where a workload proves it needs node control.
Key facts about kubernetes on Google Cloud
Kubernetes on Google Cloud in Practice
3 kubernetes scenarios from B2B procurement marketplace (SaaS), Sports technology, Insurtech (policy aggregator): the starting position, the services chosen, the architecture, the rollout and the measured outcome.
Procurement SaaS onboards enterprise tenants in a day on a GKE fleet
Live-scoring app scales 25x for match days with zero pending pods at toss
Insurtech aggregator passes IRDAI-aligned audit with signed, policy-checked GKE deploys
Ride-hailing platform moves trip and payments ledger to Spanner with zero data loss
Kubernetes on Google Cloud: Frequently Asked Questions
How is GKE Autopilot priced compared with Standard?
Autopilot bills per second for the vCPU, memory and ephemeral storage your pods request, plus the cluster management fee. Standard bills for the Compute Engine nodes you provision, whether pods fill them or not, plus the same fee. Autopilot is usually cheaper when Standard node utilization is below about 60-70%, and more expensive only for very densely packed, well-tuned clusters.
How do we migrate from self-managed Kubernetes or another cloud's managed Kubernetes to GKE?
Containers move easily; the work is in surrounding integrations. We inventory manifests, Helm charts, ingress annotations, storage classes, IAM bindings and cloud-specific controllers, then translate them to GKE equivalents such as Gateway API, Workload Identity Federation and Persistent Disk CSI. Workloads are redeployed via Config Sync into new clusters, data is migrated per stateful service, and traffic is shifted by DNS weights over two to four weeks.
Can GKE clusters keep workloads and images entirely within India?
Yes. Regional GKE clusters can run in Mumbai (asia-south1) or Delhi (asia-south2), and Artifact Registry repositories can be created in those regions so images and their scan metadata stay local. With the resource locations organization policy restricted to India, persistent volumes, backups from Backup for GKE and logs buckets are also pinned, supporting DPDP Act 2023 and sector-regulator data localization commitments.
What does Binary Authorization add if we already scan images in CI?
Scanning in CI tells you an image is safe; Binary Authorization ensures only those images run. Without it, anyone with deploy rights can push an unscanned image directly to the cluster. With it, the admission controller checks for attestations signed by your pipeline's Cloud KMS key and rejects anything else, with a logged break-glass option for emergencies.
How do we handle traffic surges that are faster than cluster scaling?
Combine three techniques: scheduled pre-scaling of HPA minimums before known events, custom-metric HPA on requests per pod so scaling starts earlier than CPU-based triggers, and spare capacity buffers using low-priority placeholder pods that real workloads preempt instantly. Image streaming and small images reduce pod start time, which matters as much as node provisioning speed.
Do we need a service mesh on GKE?
Not by default. Gateway API covers weighted routing and canaries at the edge, Dataplane V2 handles network policy, and Workload Identity Federation handles service-to-Google authentication. Add Cloud Service Mesh when you need mutual TLS between all services for compliance, fine-grained service-to-service authorization, or consistent retries and circuit breaking across dozens of services.