With GitLab 18.11 came good news for teams running GitLab on Kubernetes: Gitaly on Kubernetes is now generally available. Teams hosting GitLab on Kubernetes previously faced the challenge of maintaining a hybrid setup — running most GitLab components in Kubernetes while keeping Gitaly on virtual machines. This hybrid architecture made day-to-day operations more complex for those teams. Those days are over; Gitaly on Kubernetes is now an officially supported deployment option.The road to KubernetesGitaly has some hard requirements that don't translate naturally into a Kubernetes environment.Git operations can be memory-intensive and their usage patterns are difficult to predict. To shield the main Gitaly process from out-of-memory (OOM) events and avoid downtime, Gitaly can be configured to run each Git process inside a dedicated cgroup. In this setup, the Gitaly process lives in a separate cgroup from those used by Git processes. If a Git process exceeds its cgroup's memory limit and gets terminated, the main Gitaly process remains unaffected.Making this setup work in a Kubernetes Pod required additional work. Most Kubernetes clusters use containerd as their container runtime, and until recently, containerd only allowed containers to write to cgroupfs if they were running in privileged mode. The solution was to mount /sys/fs/cgroup via an init container and make the path writable.Pod restarts also required additional work. On a virtual machine, Omnibus can upgrade the Gitaly binary in place and reload gracefully by keeping the socket open while swapping out the process. On Kubernetes though, when a StatefulSet pod is replaced — whether due to a Helm upgrade, a node drain, or a configuration change — the Gitaly Pods are stopped and restarted. It's a hard stop, not a graceful reload. For Gitaly sharded for example, which does not offer high-availability, that means downtime which might not be acceptable for some customers.Our solution was to make client retries configurable. By configuring Gitaly clients — such as Rails — to retry requests long enough for Gitaly to restart and become available again, users may notice slightly higher latency during that brief window, but requests will ultimately succeed and downtime is avoided.To confirm that client retries effectively eliminated downtime during upgrades, we ran a series of benchmarks. We executed common Git operations against two GitLab instances — one with Gitaly on VMs, and another on Kubernetes — then triggered an upgrade mid-test and tracked request success rates. The results:OperationVM Success RateKubernetes Success Rategit clone100%100%git pull100%99.16%git push99.66%100%The numbers are nearly identical across both environments. What makes these results especially encouraging is the nature of Kubernetes itself — a Pod restart means an abrupt process termination and immediate socket closure, yet success rates remained this high. Full 100% success across every operation would require our high-availability solution, Gitaly Cluster (Praefect), which doesn't yet support Kubernetes — though that's actively being worked on, with general availability status on the horizon.What Gitaly on Kubernetes means for youIf you're running GitLab in hybrid mode — with some components on Kubernetes and Gitaly on VMs — you can now consolidate your infrastructure by moving Gitaly into the cluster. This eliminates the need to maintain and monitor a separate VM fleet alongside your Kubernetes nodes, bringing your entire GitLab stack under a single Kubernetes-managed environment.If you're adopting GitLab for the first time and you already operate software on Kubernetes, you now benefit from a fully Kubernetes-native GitLab deployment provided with our Helm chart.Installing Gitaly on KubernetesThe recommended way to deploy Gitaly on Kubernetes is through the GitLab Helm chart. Before getting started, it's worth reading through the Gitaly on Kubernetes documentation, which covers key configuration guidance and helps you avoid common pitfalls.Gitaly can be deployed either as part of a full GitLab installation, or as an external component. The Gitaly on Kubernetes documentation covers both scenarios.