Split KAS k8s-proxy into its own HTTPRoute

Clemens Beckrequested to merge
cb/fix-kas-route-setup into master

What does this MR do?

Split KAS k8s-proxy into its own HTTPRoute

The Gateway API BackendTrafficPolicy for KAS sets useClientProtocol so Envoy forwards the cross-served gRPC/WSS agent traffic as HTTP/2. The policy targeted the entire gitlab-kas HTTPRoute, which also carried the Kubernetes API proxy path (/k8s-proxy, port 8154). That backend speaks only HTTP/1.1, so forcing cleartext HTTP/2 (h2c) onto it broke kubectl requests.

Move the /k8s-proxy path to a dedicated gitlab-kas-k8s-proxy HTTPRoute that the BackendTrafficPolicy does not target, letting Envoy downgrade HTTP/2 client connections to HTTP/1.1 before reaching the proxy. The agent (port 8150) and workspaces rules stay on gitlab-kas and keep the policy.

Closes #6557 (closed)

Changelog: fixed

Related issues

Closes bug: BackendTrafficPolicy breaks KAS Kubernetes... (#6557 - closed) • Clemens Beck • 19.2

Test Plan

  1. Deploy GitLab chart from master

  2. Register an KAS agent

  3. Create a CI file doing a kubectl get pods -A using that agent

  4. Confirm this fails with something like:

    $ kubectl get pods -A
E0701 08:34:05.181367    3325 memcache.go:265] "Unhandled Error" err="couldn't get current server API group list: an error on the server (\"upstream connect error or disconnect/reset before headers. reset reason: protocol error\") has prevented the request from succeeding"
E0701 08:34:05.186244    3325 memcache.go:265] "Unhandled Error" err="couldn't get current server API group list: an error on the server (\"upstream connect error or disconnect/reset before headers. reset reason: protocol error\") has prevented the request from succeeding"

  5. Upgrade to this branch

  6. Make sure KAS and Agent Pods have been restarted

  7. Retry the CI job and confirm the kubectl commands retrieves all Pods

Author checklist

For general guidance, please follow our Contributing guide.

Required

For anything in this list which will not be completed, please provide a reason in the MR discussion.

  • Merge Request Title and Description are up to date, accurate, and descriptive.
  • MR targeting the appropriate branch.
  • MR has a green pipeline.
  • Documentation created/updated.
  • Tests added/updated.
  • Have you validated that your change works end-to-end on a real cluster deployment?
    • Describe how you did it in a comment.
  • Equivalent MR/issue for omnibus-gitlab opened.

Reviewers checklist

Edited by Clemens Beck

Merge request reports