Kubernetes Infrastructure Setup | EKS GKE AKS

Managed cluster provisioning with Terraform so the cluster configuration exists as version-controlled code rather than a collection of console clicks that cannot be reproduced. EKS cluster Terraform module: EKS managed node groups with configurable instance types (c6i for CPU-bound API services, r6i for memory-intensive data processing, g4dn for GPU workloads), IRSA (IAM Roles for Service Accounts) enabling pod-level AWS permissions via short-lived federated credentials rather than EC2 instance profiles, and EKS cluster logging (API server, audit, authenticator, scheduler logs) shipped to CloudWatch Logs. GKE cluster setup: Standard or Autopilot mode depending on whether you want node-level control or fully managed node pools; Workload Identity for GCP service account mapping; GKE Dataplane V2 (eBPF-based networking) for network policy enforcement without a separate CNI plugin. Multi-availability-zone node pools with topologySpreadConstraints on production Deployments ensuring pods are distributed across AZs so a single AZ failure reduces capacity rather than causing an outage. Cluster version upgrade planning: documented procedure for upgrading control plane (AWS manages this for EKS; GKE offers rolling upgrade with configurable surge) and node pools (cordon, drain, replace nodes one pool at a time with PodDisruptionBudgets enforcing minimum available replicas throughout). kubectl and AWS CLI/gcloud access management via IAM roles or Google Cloud IAM with kubeconfig generation documented for new team members.

Dockerfile development and Kubernetes manifest authoring for applications moving from VMs, bare metal, or ad-hoc container deployments to a structured Kubernetes workload -- with resource requests and limits set from profiling data rather than guesswork that produces OOMKilled pods or wasted capacity. Dockerfile best practices: multi-stage builds to produce minimal production images (Node.js app compiled in a node:20 build stage, copied to node:20-slim runtime stage, reducing image size from 1.2GB to 180MB); non-root user execution; .dockerignore excluding node_modules, test files, and development config; explicit version pins on base images. Kubernetes manifest development: Deployment with replicas: 2 minimum for production workloads, maxUnavailable: 0 rolling update strategy to prevent availability gaps during deploys, readinessProbe and livenessProbe configured on the application's health endpoint so traffic is only routed to healthy pods and unhealthy pods are restarted automatically. Resource request/limit calibration from profiling: the application load-tested at expected production traffic, CPU and memory consumption at p99 load measured, requests set at the p50 measurement, limits set at 2x the p99 peak to allow bursting without OOM kills. Helm chart development for multi-environment deployments: a single chart with values.yaml defaults and values-staging.yaml/values-production.yaml overlays providing environment-specific image tags, replica counts, resource limits, and ingress hostnames -- a single helm upgrade command per environment rather than maintaining separate manifest files.

Autoscaling configured to match your application's actual traffic patterns -- scaling out before user-facing latency degrades and scaling in promptly enough to reduce cloud cost during off-peak periods without causing thrashing. Horizontal Pod Autoscaler (HPA) configuration: CPU utilisation target set at 60-70% (leaving headroom before new pods become ready to serve traffic, typically 30-60 seconds after scale-out triggers); custom metrics HPA via the Prometheus adapter for applications where request queue depth or active WebSocket connection count is a better scaling signal than CPU; KEDA (Kubernetes Event-Driven Autoscaling) for scale-to-zero on background processing workloads that should consume no pod resources when their SQS/Kafka/RabbitMQ queue is empty. Cluster Autoscaler for EKS/GKE/AKS: adds nodes when pods are pending due to insufficient capacity; removes nodes when utilisation has been below the scale-down threshold for a configurable window (typically 10 minutes); node group configuration with minimum and maximum bounds to prevent unbounded scale-out. Vertical Pod Autoscaler (VPA) in recommendation mode: reports the 7-day p95 CPU and memory usage per container and recommends updated request/limit values -- without automatically applying changes that would require pod restarts during business hours. Load testing with k6 or Locust at 2x expected peak traffic before production launch: scaling behaviour observed, scale-out latency measured, and the time-to-ready for new pods confirmed acceptable before user-facing traffic tests the configuration.

Kubernetes networking configured from the cluster CNI through to the external ingress layer -- with TLS, network policies, and service discovery established correctly before workloads are deployed rather than retrofitted after. Ingress controller selection and configuration: NGINX Ingress Controller for clusters requiring fine-grained annotation-based routing, rewrite rules, and rate limiting per path; AWS ALB Ingress Controller for EKS clusters where native ALB integration provides better AWS-ecosystem alignment (WAF, Shield, ACM certificate management); Traefik for teams who prefer dashboard-based routing visibility and automatic service discovery via Kubernetes annotations. TLS certificate management with cert-manager: ClusterIssuer configured for Let's Encrypt ACME HTTP-01 or DNS-01 challenge (DNS-01 required for wildcard certificates); certificates automatically provisioned and renewed 30 days before expiry; Certificate resources committed to Git so the expected certificate state is version-controlled. NetworkPolicy configuration using Calico or the cluster's built-in CNI network policy support: default-deny ingress policy applied to all namespaces, then explicit allow policies for each required service-to-service communication path (e.g., API service may receive traffic from ingress controller and internal cron namespace; database service may receive traffic from API service only). Service mesh evaluation for teams needing mutual TLS between services: Istio for comprehensive traffic management (circuit breaking, retries, canary deployments via VirtualService); Linkerd for lower operational overhead with automatic mTLS. CoreDNS configuration for internal service discovery (service.namespace.svc.cluster.local) and external DNS resolution.

Persistent storage and stateful workload configuration for applications that need durable data beyond pod restarts -- the component of Kubernetes configuration that requires the most careful design because getting it wrong can cause data loss. StorageClass configuration per environment: gp3 EBS volumes for EKS production workloads with reclaimPolicy: Retain (deleted PVCs leave the underlying volume intact for recovery); gp2 for development environments with reclaimPolicy: Delete for cost management; GCP Persistent Disk with regional replication for GKE production stateful workloads. StatefulSet deployment for applications requiring stable network identities: each pod receives a stable DNS name (pod-0.service.namespace.svc.cluster.local) and its own PersistentVolumeClaim that persists across pod restarts -- the deployment model required for distributed databases and message queues where node identity matters. Operator-based deployment for production databases: CloudNativePG operator for PostgreSQL (automated failover, streaming replication, WAL archiving to S3, PITR restore capability); Redis Operator for Redis (Sentinel-based HA, automated failover); Strimzi for Kafka (topic management, user management, rolling upgrade coordination) -- so day-two operations are handled by the operator's reconciliation loop rather than manual operator intervention. Persistent volume backup strategy: Velero for cluster-level backup (PersistentVolumes plus Kubernetes resource definitions); database-specific backup via the relevant operator (CloudNativePG WAL archiving, Redis BGSAVE) with restore procedures tested quarterly and restore time documented (target RTO under 30 minutes for a complete restore from backup).

Kubernetes security configuration applied at every layer -- RBAC, admission control, pod security, network policy, image security, and secrets management -- because a Kubernetes cluster with permissive defaults is a larger attack surface than the VMs it replaced. RBAC configuration: separate namespaces per team (frontend, backend, data) and per environment (dev, staging, production) with ClusterRole/Role definitions granting the minimum permissions required; service accounts for workloads that need Kubernetes API access (e.g., operators, CI deployments) with specific resourceRule grants rather than cluster-admin; kubectl auth can-i audit of every service account role binding before production launch. Pod Security Standards: baseline profile enforced via namespace admission controller labels to block privileged containers, containers running as root, hostNetwork/hostPID/hostIPC access, and dangerous capabilities (NET_ADMIN, SYS_ADMIN); restricted profile applied to namespaces where the workloads have been validated to operate without elevated privileges. Image security via Trivy scanning in CI: images scanned for known CVEs before each deployment; HIGH and CRITICAL severity findings block the pipeline; a suppression file for accepted false positives reviewed quarterly. Secrets management: External Secrets Operator deployed to sync secrets from AWS Secrets Manager or HashiCorp Vault into Kubernetes Secret objects at runtime -- preventing application secrets from being committed to the Helm values repository and enabling rotation without pod restarts when the operator is configured with a sync interval. Admission webhook integration with OPA/Gatekeeper or Kyverno for policy-as-code enforcement: custom policies blocking deployments without resource limits, blocking images from unapproved registries, and requiring specific label sets on all workloads for cost allocation.