Google Cloud (Containers and Application Hosting): From Container Images to Running Applications (Part 2)

Building an application is only the beginning. You also need to deploy it, expose it securely, handle changing traffic, monitor failures, and release updates.

Google Cloud offers several hosting options. GKE provides Kubernetes capabilities, Cloud Run simplifies container hosting, Cloud Run functions handles function-based workloads, and App Engine provides a managed application platform.

GKE Autopilot and GKE Standard are operating modes of GKE, rather than separate Kubernetes products.

The scenarios below are illustrative designs, not descriptions of a particular company’s production environment.

1. Google Kubernetes Engine — Manage containerized applications with Kubernetes

GKE is Google Cloud’s managed Kubernetes service. You deploy applications using Kubernetes resources such as Deployments, Services, ConfigMaps, and PersistentVolumeClaims.

Google manages the control plane. Your operational responsibilities depend on the selected mode, but application configuration, access controls, and workload reliability still require attention.

Practical example: a banking microservices platform

An application contains login, account-summary, and payment services. Each service has its own deployment and can be updated independently.

Suggested deployment workflow

1. Build and scan the container image.
2. Publish it to Artifact Registry.
3. Update the approved deployment configuration.
4. Deploy through your CI/CD or GitOps workflow.
5. Verify startup, readiness, and application behavior.
6. Monitor the rollout before completing the release.

For your Helm and Argo CD experience, GKE is a natural place to demonstrate the same Kubernetes deployment practices.

Useful investigation commands

kubectl get deployments,pods,services -n demo
kubectl describe pod POD_NAME -n demo
kubectl logs POD_NAME -n demo --all-containers
kubectl get events -n demo --sort-by=.metadata.creationTimestamp
kubectl rollout status deployment/APP_NAME -n demo

Replace the placeholders with your resources.

Interview question: What does managed Kubernetes mean?

Google operates the Kubernetes control plane and provides infrastructure-management capabilities. We still manage application deployments, workload security, resource configuration, and application availability.

Common mistake: Assuming a managed cluster makes an application highly available automatically. Replicas, placement, health checks, and dependency design matter.

2. GKE Autopilot — Focus on workloads while Google manages the nodes

Autopilot automates node provisioning and management and applies workload security constraints. You continue to deploy Kubernetes resources and define workload requirements.

Practical example: A team runs customer-profile APIs using Helm charts. It wants Kubernetes capabilities while reducing routine node administration.

What your team still manages

• Container images and releases.
• Requests, limits, and application scaling.
• Startup, readiness, and liveness probes.
• Service access and workload identities.
• Application monitoring and recovery.

Interview question: Does Autopilot support every workload that Standard supports?

I would verify the workload’s requirements against Autopilot capabilities. Workloads needing unusual host access or privileged operations require particular attention; some supported privileged workloads use allowlists.

Common mistake: Saying “Autopilot means no operations.” It reduces infrastructure work, but application operations remain.

Also avoid describing its billing as universally “per Pod”: pricing depends on the workload and compute configuration.

3. GKE Standard — Configure the infrastructure around your workloads

Standard provides greater control over node pools and infrastructure configuration. Teams can configure capacity and upgrade strategies around their requirements; Google still manages the control plane.

Practical example: A platform uses separate capacity for general APIs and memory-intensive processing.

Operational responsibilities to plan

Interview question: Why choose Standard over Autopilot?

I choose Standard when a verified workload requirement needs greater infrastructure control. I compare compatibility, operational effort, security requirements, and cost before deciding.

Troubleshooting example: A Pod remains Pending. Inspect its events for insufficient resources, scheduling restrictions, or storage issues before simply adding nodes.

4. Cloud Run — Deploy containers without managing a Kubernetes cluster

Cloud Run provides managed execution for containers. Services handle requests, while jobs execute work that finishes. Services support revisions, traffic splitting, and automatic scaling, including scaling to zero when configured appropriately.

Persistent business data belongs in external storage rather than the disposable local filesystem.

Practical example: a quotation API

A containerized API receives a request, calculates a quotation, stores the result, and returns a response.

Suggested hands-on exercise

1. Containerize a small API.
2. Publish its image to Artifact Registry.
3. Deploy a Cloud Run service.
4. Configure its identity, ingress, and authentication.
5. Test authenticated requests.
6. Deploy a second revision and test a gradual rollout.

Interview question: What is a cold start?

It is the startup delay when a request requires a new instance. I reduce startup work and evaluate minimum instances when the latency requirement justifies keeping capacity active.

Common mistake: Assuming Cloud Run cannot host private services. Access can be restricted through authentication and ingress configuration.

5. Cloud Run functions — Execute focused code on requests or events

Cloud Run functions lets you deploy function source code for HTTP or event-driven execution. The platform builds the source into a container and runs it on Cloud Run.

Practical example: document-upload processing

When a customer uploads a document, a function validates it and records a processing result.

Practical design considerations

• Use a dedicated identity with necessary permissions.
• Keep credentials in approved secret storage.
• Validate file type and size.
• Make processing safe to retry.
• Record event and object identifiers for investigation.

Interview question: Why must event-driven processing be idempotent?

Events can be delivered more than once. Processing the same event repeatedly should not create duplicate records or repeat an irreversible business action.

For example, use the object name and generation as part of a processing identifier, and check whether that version has already completed.

Common mistake: Making a duplicate event generate a duplicate customer notification or financial record.

6. App Engine — Host applications on a managed platform

App Engine has Standard and Flexible environments. Standard uses supported runtime environments; Flexible runs containers on managed Compute Engine VMs.

Google currently recommends evaluating Cloud Run for new users and upcoming projects. App Engine remains relevant when documenting or operating existing applications.

Practical example: An existing customer-support portal runs on App Engine, with separate services for its frontend and backend.

Interview question: Why does the environment choice matter?

It changes runtime compatibility, scaling behavior, startup characteristics, and cost. I check application dependencies before choosing.

Common mistake: Assuming Flexible scales to zero like Standard.

How to choose a hosting option

This is a starting point. Confirm networking, security, runtime, availability, and cost requirements before committing.

A combined real-world design

An organization can use different hosting options for different workloads:

A useful interview answer

“I choose hosting based on workload requirements. For Kubernetes capabilities, I evaluate GKE and decide between Autopilot and Standard based on the infrastructure control needed. For independent container services, I evaluate Cloud Run. For focused HTTP or event handlers, I consider Cloud Run functions. For existing App Engine applications, I assess operational needs and migration benefits.”