Infrastructure Troubleshooting Master Guide: Docker, Kubernetes, GCP Cloud Run, Cloudflare

Infrastructure Troubleshooting Master Guide: Docker, Kubernetes, GCP Cloud Run, Cloudflare


With the adoption of container virtualization and cloud computing, infrastructure configuration has grown increasingly complex. Code that runs flawlessly on a local developer machine can crash in a production environment due to mismatched environment variables, missing permissions, or network timeouts.

This guide covers container optimizations, Kubernetes debugging workflows, serverless (GCP Cloud Run) latency adjustments, and security configurations via Cloudflare and Supabase.


1. Container Optimization: Reducing Docker Image Footprints

Oversized Docker images degrade deployment speeds (prolonging Image Pull phases) and increase the potential security attack surface area.

Multi-Stage Builds

Separate your build environment (containing heavy SDKs and compilers) from your final runner container, transferring only compiled binaries or production assets.

  • Node.js Production Dockerfile Example:
    # Stage 1: Build stage
    FROM node:18-alpine AS builder
    WORKDIR /app
    COPY package*.json ./
    RUN npm ci
    COPY . .
    RUN npm run build
    
    # Stage 2: Production runner stage
    FROM node:18-alpine AS runner
    WORKDIR /app
    ENV NODE_ENV=production
    COPY package*.json ./
    # Install only production dependencies
    RUN npm ci --only=production
    # Copy compiled build output from Stage 1
    COPY --from=builder /app/dist ./dist
    
    EXPOSE 3000
    CMD ["node", "dist/index.js"]
  • Results: Eliminating build tools and caches reduces image sizes by over 70%. For further optimization, consider using Distroless or Alpine base images.

2. Kubernetes Pod Diagnostics & Troubleshooting

When a service running on a Kubernetes cluster fails, you must quickly locate the root cause using standard command-line tools.

Common Pod Failure States

  • CrashLoopBackOff: The container starts, encounters an error, and terminates immediately, repeating the cycle. This is usually caused by missing environment variables, wrong launch commands, or directory permission errors.
  • OOMKilled: The container attempted to consume more memory than allowed by its Resource Limits, triggering the Linux kernel’s Out-Of-Memory Killer.
  • ImagePullBackOff: Kubernetes failed to download the image. Check registry authentication secrets or look for typos in the image tag.

Essential Diagnostic Commands

# 1. Inspect Pod details and system events (best for checking status changes)
kubectl describe pod <pod-name>

# 2. Review logs of a crashed or terminated container instance
kubectl logs <pod-name> --previous

3. Resolving GCP Cloud Run Cold Starts

GCP Cloud Run and serverless containers scale down instances to zero during idle periods to reduce costs. However, this causes latency spikes (Cold Starts) for the initial incoming requests as a new container is provisioned.

Cold Start Mitigation

  • Set Minimum Instances: Configure min-instances to at least 1 to keep a warm runner container active, eliminating startup latency for incoming traffic.
  • CPU Allocation “Always On”: By default, CPU allocation is throttled outside active request handling. Keeping CPU always allocated ensures background schedulers, caches, and connection pools initialize immediately.
  • Lightweight Containers: Slim down base images and minimize application startup dependencies.

4. Network and Security Controls: Cloudflare & Supabase

Cloudflare Proxy Status

Enabling proxying (the orange cloud icon in your DNS settings) routes web traffic through Cloudflare’s network, offering several advantages:

  • Origin Protection: Mask your server’s public IP address to mitigate DDoS attacks.
  • SSL/TLS Encryption Modes: Use Full if your server uses self-signed certificates, and Full (strict) if your server uses a verified certificate authority (CA) to guarantee secure transit encryption.

Supabase Row Level Security (RLS)

Supabase exposes PostgreSQL directly to client SDKs. Restricting access through RLS policies is essential to data security.

  • Security Rule: Always enable RLS on every table and define explicit policies (e.g., verifying user IDs via auth.uid()) to prevent clients from executing malicious queries against other users’ private data rows.

Start Here

Continue with the core guides that pull steady search traffic.