Enable independent component deployments to support scaling GitLab.com infrastructure

Problem Statement

Currently, all GitLab.com Kubernetes components (GitLab application, Container Registry, KAS, etc.) are deployed as a single monolithic Helm release. This creates several operational challenges:

1. Deployment Blocking: Components cannot be deployed independently - if a GitLab application deployment is in progress, other component updates must wait until completion
2. Build Time Inefficiency: Components with fast build times (minutes) are forced to wait for full GitLab builds that take almost 1 hour
3. Limited Deployment Windows: With infrastructure frequently busy deploying GitLab versions and production change requests competing for the same time slots, finding windows for component updates becomes increasingly difficult
4. Scaling Concerns: We have ~10 new components forecasted to be added, which will exacerbate the deployment scheduling problem
5. Rollback Limitations: Issues with one component require rolling back the entire stack, even if other components are functioning correctly

Current Architecture

All components are managed within the same gitlab Helm release in k8s-workloads/gitlab-com, configured through:

• Shared values.yaml.gotmpl
• Common init-values.yaml.gotmpl for version management
• Unified deployment pipelines

Proposed Solution

Phase 1: Architecture Design

• Evaluate current monolithic approach and design a paved road solution for independent component deployments
• Define standardized patterns and tooling that can be applied consistently across all components
• Create reusable deployment templates and automation frameworks

Phase 2: Independent Component Deployment

• Split suitable components into separate Helm releases
• Implement per-component auto-deploy automation similar to current GitLab application auto-deploy
• Create component registry service to manage desired versions and trigger deployments

Phase 3: Automation Enhancement

• Develop component registry service that will act as the single source of truth for GitLab auto-deploy, replacing the current distributed version management
• At release time, propagate each component version to all packagers (Omnibus, CNG)
• Extend auto-deploy patterns to all suitable components

Expected Benefits

1. Parallel Deployments: Components can be updated independently without blocking each other
2. Faster Time-to-Production: Fast-building components don't need to wait for lengthy GitLab application builds or deployment windows
3. Reduced Risk: Smaller, focused deployments with limited blast radius
4. Independent Rollbacks: Ability to rollback individual components without affecting the entire stack
5. Operational Scalability: Can accommodate the forecasted 10+ new components without deployment scheduling conflicts
6. Team Autonomy: Different teams can manage their component deployment cycles independently