A production-ready Kubernetes platform on EKS with Karpenter, GitOps, service mesh, full observability stack, and security hardening: built to run real workloads.
4–10 weeks
$30k–$70k
We start by designing the right cluster architecture for your workloads. The key decisions:
Node management: Managed Node Groups (simple, less control), Karpenter (intelligent provisioning from the EC2 Fleet API, significantly better cost optimization), or Fargate Profiles (serverless nodes, limited flexibility). For most production clusters we recommend Karpenter with a fallback managed node group for system workloads.
Multi-cluster vs single cluster: a single cluster per environment (dev, staging, prod) is right for most teams. Multi-cluster is justified when you need strict blast-radius isolation between business units, different compliance scopes, or independent upgrade cadences.
Networking: VPC CNI is the standard networking plugin for EKS — pods get real VPC IP addresses, which simplifies security group integration and load balancer routing. Configure prefix delegation to increase pod density per node (critical when using smaller instance types). Plan your Pod CIDR and Service CIDR to avoid subnet exhaustion at scale.
We configure and manage the standard EKS add-ons:
VPC CNI: manages pod networking. Configure prefix delegation for higher pod density.
CoreDNS: cluster DNS. Tune replicas and resource requests based on cluster size.
kube-proxy: manages iptables rules for Service routing.
Amazon EBS CSI Driver: enables PersistentVolumes backed by EBS. Required for stateful workloads.
Amazon EFS CSI Driver: enables ReadWriteMany PersistentVolumes backed by EFS.
Metrics Server: required for HPA (Horizontal Pod Autoscaler) to function.
Karpenter replaces Cluster Autoscaler for new EKS deployments. Instead of scaling predefined node groups, Karpenter watches the Kubernetes scheduler's pending pod queue and provisions exactly the right EC2 instance type from any family you allow. New nodes are ready in 30–60 seconds (vs 3–5 minutes for Cluster Autoscaler).
NodePool design: we create NodePools for different workload classes — a default Spot pool that accepts most workloads (diversified across m5, m6i, c5, c6i, r5, r6i families and multiple sizes), an on-demand pool for workloads that cannot tolerate spot interruptions (stateful services, critical control plane components), and a GPU pool if ML inference workloads are present.
Karpenter consolidation: the background loop that continuously evaluates whether the existing node fleet can be compacted — draining underutilized nodes and rescheduling pods onto fewer, better-utilized nodes. Teams typically see 20–40% additional cost reduction from consolidation beyond what spot alone provides.
Both Argo CD and Flux implement GitOps for Kubernetes — the principle that all cluster state is defined in Git and automatically reconciled. The choice:
Argo CD: web UI for visualizing sync status and drift, ApplicationSet for templated multi-cluster/multi-env deployments, built-in RBAC. Better for teams that value visibility and a GUI for approvals.
Flux: lightweight, no UI by default, purely declarative via CRDs, excellent Helm integration with Flux HelmRelease. Better for teams that want minimal footprint and GitOps purity.
We default to Argo CD for most teams because the visibility into sync state and application health significantly reduces operational burden.
The AWS Load Balancer Controller creates and manages ALBs and NLBs from Kubernetes Ingress and Service resources. This is the standard approach for EKS ingress — it integrates natively with ACM (TLS termination), WAF, security groups, and target group health checks.
For teams needing advanced routing (canary, header-based routing, authentication at the ingress layer), we layer NGINX Ingress Controller in front of the ALB, or use Kong Gateway for API management capabilities.
Service mesh decisions depend on your requirements:
Istio: the most feature-complete option — mTLS between all services, fine-grained traffic policies, circuit breaking, canary deployments via VirtualService/DestinationRule. Significant operational overhead. Right for teams with strict service-to-service security requirements or advanced traffic management needs.
Linkerd: lighter than Istio, excellent performance, simpler operational model. mTLS, observability, and basic traffic management. Right for teams that want the security benefits of a mesh without the Istio complexity.
AWS App Mesh: reached end of support on September 30, 2026. On ECS, AWS's migration path is Service Connect; on EKS, Istio or Linkerd.
For most teams we start without a service mesh and add one when the specific need arises (e.g., mutual TLS becomes a compliance requirement).
We deploy the kube-prometheus-stack (Prometheus Operator + Grafana + Alertmanager) as the foundation:
Prometheus: scrapes metrics from all cluster components and workloads via ServiceMonitors and PodMonitors
Grafana: dashboards for cluster health, workload performance, cost (via Kubecost integration)
Alertmanager: routes alerts to PagerDuty, Slack, or your preferred alerting destination
Loki + Promtail: log aggregation correlated with Prometheus metrics via Grafana's LogQL
OpenTelemetry Collector: DaemonSet for trace collection from instrumented applications, forwarded to X-Ray or a backend of your choice
Admission control: Kyverno for policy-as-code. We write Kyverno ClusterPolicies for: required resource requests and limits, prohibited privileged containers, required security context settings, image registry restrictions (ECR only in production), and Cosign signature verification for production images.
Pod Security Standards: enforce the baseline or restricted standard via namespace labels or Kyverno, blocking pods that request excessive privileges.
IRSA / EKS Pod Identity: every workload that needs AWS access (S3, RDS, SQS, etc.) gets an IAM role scoped to its specific service account and namespace. No long-lived AWS credentials in the cluster.
Falco: DaemonSet for runtime syscall monitoring. Alerts on unexpected shell execution in containers, unexpected network connections, privilege escalation attempts.
Node hardening: IMDS hop limit set to 1 (prevents pods from accessing the instance metadata service), EBS volume encryption enabled, EKS-optimized AMIs only.
Kubecost (or the open-source OpenCost) provides per-namespace, per-deployment cost visibility within the cluster — critical for chargeback in multi-team environments. We configure Karpenter consolidation, Spot instance diversification, and namespace-level ResourceQuotas to prevent runaway costs.
We deliver the cluster with a Helm + helmfile or Kustomize-based configuration management approach. All add-ons and platform components are managed in Git, deployed via Argo CD or Flux. New application teams onboard by submitting a Helm chart or Kustomize overlay to the GitOps repository.
EKS cluster with Karpenter NodePools configured for your workload mix
Argo CD or Flux GitOps deployment pipeline
Observability stack: kube-prometheus-stack + Loki + OTel Collector
Kyverno security policies library
AWS Load Balancer Controller + Ingress configuration
Kubecost or OpenCost for cost visibility
Runbooks: cluster upgrade procedure, Karpenter NodePool management, incident response
Team onboarding documentation
Tell us about your current environment and goals. We'll review the details and respond with a proposed engagement structure and timeline.
Typical response time: 1–2 business days.
Prices and timelines are estimates for typical engagements, not offers. Scope, price and terms are set in a written agreement after we understand your situation. Terms of use.