Investigate Alternatives to Kubernetes for Workspaces Setup

MR: Draft: POC: Run a workspace in a Cloud VM (!174200 - closed)

Explore alternative approaches for setting up and delivering GitLab Workspaces that do not rely on Kubernetes. One potential solution is leveraging virtual machines (VMs) through cloud providers like AWS (e.g., EC2 instances) or GCP, allowing clients to spin up VMs corresponding to Workspaces.

Objectives:

• Assess the feasibility of using VMs as a lower barrier to entry compared to Kubernetes clusters.
• Consider how to simplify end-to-end adoption for Workspace Admins.
• Identify potential advantages over Kubernetes-based setups.

TODO:

1. Get KAS HTTP proxy working
2. Test VS Code via KAS HTTP proxy
3. Get KAS HTTP proxy and VS Code in a CI Job service
4. Build SSH over gRPC tunnel
5. Get Ci::Workload to include a VS Code container and Kas Agent HTTP proxy container
6. Test out using CI Cache as persistence for workspace dir
7. Get KAS SSH tunnel working
8. Tunnel SSH through gitlab-shell to KAS agent?
9. How will persistence work across restarts of a workspace?
10. How will GitLab detect if a workspace is gone and needs to be restarted?
11. Create blueprint proposal for reverse tunnel gRPC ingress
12. Create blueprint for Runner workspace creation