Cluster architecture
EKS, GKE, node pools, add-ons, scaling, isolation, and lifecycle decisions.
Kubernetes consulting for clusters your team can actually operate.
Running Kubernetes is easy to start and considerably harder to maintain well. We design, improve, and troubleshoot production Kubernetes environments, including EKS and GKE. Our focus is on predictable upgrades, consistent workloads, understandable networking, and operations your team can manage without relying on a few specialists. We also help determine when Kubernetes is introducing more complexity than the application needs.
The problem
The cluster is running. Changing it is the difficult part.
The cluster is already running. Changing it safely is the work that keeps getting deferred.
Workload settings
As found
- not set
| Workload | Requests | Probes | Rollout | Disruption budget |
|---|---|---|---|---|
| api | set | liveness only | recreate | not set |
| worker | not set | not set | rolling | not set |
| web | oversized | set | custom script | set |
| cron | not set | not set | not set | not set |
Upgrade
- n
- n+1
Upgrade untested, postponed
01
Upgrades keep getting postponed
Nobody has a tested upgrade process or a complete picture of the add-ons and dependencies that may break.
02
Workloads are configured inconsistently
Resource requests, probes, deployment strategies, and disruption policies differ across services without good reasons.
03
Networking is difficult to understand
Ingress, service-to-service communication, identity, and network policies have grown through incremental fixes.
04
More clusters created more operational work
New clusters solved immediate isolation or deployment problems but introduced additional maintenance and configuration drift.
What changes
Make Kubernetes easier to change, upgrade, and debug.
Repeatable cluster operations
Upgrades and configuration changes follow a documented, tested process.
Workload settings
- not set
- from the contract
| Workload | Requests | Probes | Rollout | Disruption budget |
|---|---|---|---|---|
| api | set | liveness only | recreate | not set |
| worker | not set | not set | rolling | not set |
| web | oversized | set | custom script | set |
| cron | not set | not set | not set | not set |
Upgrade
- n
- n+1
Upgrade untested, postponed
| Workload | Requests | Probes | Rollout | Disruption budget |
|---|---|---|---|---|
| Shared contract | sized | ready + live | rolling | set |
| api | meets the contract | meets the contract | meets the contract | meets the contract |
| worker | meets the contract | meets the contract | meets the contract | meets the contract |
| web | meets the contract | meets the contract | meets the contract | meets the contract |
| cron | meets the contract | meets the contract | meets the contract | meets the contract |
Upgrade
- n
- rehearse
- n+1
Documented, rehearsed upgrade
Consistent workload expectations
Applications use clear defaults for deployment, scaling, networking, security, and observability.
Fewer unnecessary components
Add-ons, clusters, and abstractions have defined purposes and owners.
Kubernetes engineering services.
Workload configuration
Resource management, probes, rollout strategies, autoscaling, and disruption handling.
Networking
Ingress, Gateway API, CNIs, network policy, and service meshes where justified.
Security
Workload identity, RBAC, admission policies, secrets, and configuration controls.
Upgrades and maintenance
Planned upgrades with dependency checks, rehearsals, and recovery procedures.
Migrations
Cluster consolidation, provider migrations, and movement to or from Kubernetes when appropriate.
Understand the cluster before changing its architecture.
How the work runs
01
Inspect the running environment
Review cluster versions, workloads, networking, add-ons, policies, and operational risks.
02
Define the target configuration
Agree on the workload contract, ownership boundaries, and components that need to remain.
03
Implement repeatable configuration
Use infrastructure as code and suitable desired-state tooling to make changes reviewable.
04
Validate operations
Test upgrades, failure handling, and diagnostic workflows with your engineers.
Technologies
Used when they fit the system you already run. Not as a checklist.
EKS · GKE · Kubernetes · Cilium · Istio · Argo CD · Helm · Kustomize
From the notes
Common questions
Is Kubernetes the right choice for our applications?
Not always. A team with a small number of services may be better served by a simpler managed runtime. We assess the operational requirements before recommending more Kubernetes infrastructure.
Do you work with EKS and GKE?
Yes. We work with managed Kubernetes on AWS and Google Cloud, while accounting for the differences in their networking, identity, and cluster operations.
Should we introduce a service mesh?
Only when requirements such as workload identity, service-to-service traffic control, or migration policies justify its operational cost. A mesh is not a default component of every cluster.
Can you help with a cluster we already run?
Yes. Existing clusters are often the most useful starting point. We can review their architecture, resolve specific operational problems, and improve maintainability without rebuilding everything.
Related
- Platform engineering
Developers should not need to understand the entire infrastructure stack to ship a service. We create supported development and deployment workflows, reusable templates, and self-service capabilities that reduce dependence on a handful of infrastructure specialists.
- DevOps & CI/CD
Releasing software should not require undocumented procedures or fragile pipelines. We improve builds, tests, deployment automation, GitOps, and release workflows so changes move through a clear and repeatable process.
- SRE & observability
Production should be understandable before, during, and after an incident. We design telemetry, alerting, service-level objectives, incident response practices, and the operational workflows that turn signals into decisions.
- Cloud infrastructure
Cloud environments need clear boundaries, identity, networking, and operational defaults. We design and improve AWS and GCP foundations that teams can extend without recreating everything for each environment.
Platform assessment
Know what needs fixing before committing to a rebuild.
Our Platform & DevOps Assessment examines the infrastructure, delivery process, operational risks, and cloud costs you already have. You receive prioritized findings and a practical 90-day roadmap, including what to fix first, what can wait, and what should be left alone.