Kubernetes Consulting
Clusters on EKS, GKE, AKS, or in a private data center. Helm, GitOps, and a deploy path application teams can use.
Who this is for
- Teams adopting Kubernetes, or replacing a cluster they run by hand
- Application teams that still need a person to deploy for them
- A cluster that sits next to virtual machines
The cluster and the deploy
The cluster, its networking, and its secrets. Helm and GitOps (Argo CD or Flux) so an application team can deploy the service they already own.
A baseline the cluster keeps
A baseline for the cluster, approved images, and a registry the cluster is allowed to pull from. Clusters still on retired ingress-nginx move to Gateway API: non-production first, then production.
Upgrades and capacity
Upgrades, and resource quotas so one team cannot take all of the cluster.
Capabilities
- Cluster architecture on EKS, GKE, AKS, or in a private data center
- Helm, Kustomize, and GitOps (Argo CD, Flux)
- Gateway API, including moving off retired ingress-nginx
- Upgrades, capacity, and resource quotas
Example: GKE Gateway API migration
Common questions
Which Kubernetes do you run?
EKS, GKE, AKS, and private Kubernetes, including clusters that sit next to virtual machines.
Can you help if production has no outbound internet?
Yes. The cluster can sit on a network with no outbound internet. Mirrors and per-zone runners keep promotion inside the boundary.
Is this the cluster, or the path developers use?
Either or both. We can work on the cluster, on the deploy path an application team uses without a ticket, or on both in one engagement.