Docker & Kubernetes Engineering

Docker Compose is great for local development and simple single-server deployments. Kubernetes makes sense when you need automatic failover, horizontal scaling, rolling deployments, or are running more than a handful of services. A useful threshold: if you have more than 5 services or more than 3 engineers deploying to production, Kubernetes pays for its complexity. Below that, a managed platform like Railway or Render plus Docker often gives you 80% of the benefit with 20% of the ops work.

We work with EKS (AWS), GKE (Google Cloud), AKS (Azure), and self-managed clusters on bare metal or virtual machines. For most startups we recommend EKS or GKE because the managed control plane eliminates a significant operational burden. We have also worked with k3s for edge and IoT deployments where a lightweight distribution is required.

We use multi-stage builds to keep the final image as small as possible - often under 50MB - which reduces both attack surface and pull time. We run processes as a non-root user, avoid copying unnecessary files with .dockerignore, pin base image versions by digest, and scan images with Trivy in CI. Images that fail security scans block the pipeline.

We never store secrets as plain-text Kubernetes Secrets (they are only base64-encoded, not encrypted). Instead we use the Secrets Store CSI Driver to mount secrets from AWS Secrets Manager, HashiCorp Vault, or GCP Secret Manager directly into pods. Secrets are rotated automatically and pods receive updated values without a restart when possible.

We configure Horizontal Pod Autoscaler (HPA) based on CPU, memory, or custom metrics via KEDA - for example, queue depth from SQS or Kafka. We also set up Cluster Autoscaler to add and remove nodes automatically, and Vertical Pod Autoscaler to right-size resource requests over time. The result is a cluster that handles traffic spikes without over-provisioning for off-peak periods.

GitOps means using git as the single source of truth for your cluster state. Every change - scaling a deployment, updating a config, rotating a secret reference - goes through a pull request. ArgoCD continuously reconciles the cluster against the desired state in git and alerts on drift. The result is a complete audit trail, peer review of every infrastructure change, and automatic recovery if someone accidentally modifies the cluster directly.

Kubernetes Deployments perform rolling updates by default, replacing pods gradually while maintaining availability. We configure maxUnavailable and maxSurge to control the rollout speed. Rollback is a single command (kubectl rollout undo) or, with GitOps, a git revert - the previous image is redeployed automatically. We also integrate deployment health checks that pause a rollout if the new pods are crashing.

Yes, when the complexity is justified. A service mesh like Istio or Linkerd provides mutual TLS between services, fine-grained traffic policies (canary routing, circuit breaking), and detailed telemetry without modifying application code. We typically introduce a service mesh when you have 10+ services with service-to-service communication and need mTLS for compliance or traffic management for canary releases.

We deploy the kube-prometheus-stack (Prometheus Operator, Grafana, AlertManager) for cluster and workload metrics, and Loki for log aggregation. We set up pre-built Kubernetes dashboards covering node health, pod resource usage, HPA status, and PersistentVolume capacity. Alerts route to Slack and PagerDuty with runbooks attached so the on-call engineer knows what to do.

Stateful workloads like databases use StatefulSets with PersistentVolumeClaims backed by cloud-native storage (EBS, GCS PD). However, for most production use cases we recommend running databases outside the cluster - on RDS, Cloud SQL, or managed MongoDB - where backup, failover, and patching are handled by the cloud provider. Running stateful databases in Kubernetes adds operational complexity that is rarely worth it.

Yes. We use Kompose to get a baseline translation, then refine the manifests to follow production best practices - adding resource limits, health probes, horizontal scaling, and proper secret management. We do not skip the refinement step; raw Kompose output is rarely production-ready. The migration is done service by service with parallel environments so there is no big-bang cutover.

Cluster maintenance includes Kubernetes version upgrades (we target no more than 2 minor versions behind), node image patching, certificate rotation, etcd backups, and periodic review of resource limits and requests. With EKS or GKE, the control plane is managed automatically; node groups still need planned upgrades. We handle this as part of our managed infrastructure retainer or document the process for your team to own.