-
Notifications
You must be signed in to change notification settings - Fork 39k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OpenAPI spec fetching ignores apiserver URL path #117463
Comments
/sig api-machinery |
FYI @seans3 |
/triage accepted |
/assign |
I thought that this was going to be fixed in Kubernetes 1.27.2 - but this doesn't seem to be the case. |
are you using updated v0.27.2 client libraries? |
I just updated the cluster per https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/ and rebuilt a container image and ran the Gitlab agent to re-deploy it. I'm not sure where the client libraries are used in this process, but will do some research to find out. |
Thanks, @ligett - I had carefully updated the server, but neglected to update kubectl. Now that I have done that, the Gitlab build works fine with Kubernetes 1.27.2. |
What happened?
This was originally reported in https://gitlab.com/gitlab-org/gitlab/-/issues/407161. GitLab Agent for Kubernetes, apart from other things, is a Kubernetes API reverse proxy. Users recently started getting errors when using it with kubectl v1.27.x.
Users' CI jobs get a generated kubectl-compatible config file, where server URL has a path component. For GitLab.com the address is
https://kas.gitlab.com/k8s-proxy/
. Looks like kubectl v1.27.x ignores the path component for some OpenAPI requests - here is an output for akubectl apply
run:Important bits - request is made to
https://kas.gitlab.com/openapi/v3/apis/apps/v1
but should behttps://kas.gitlab.com/k8s-proxy/openapi/v3/apis/apps/v1
:The error that is reported is a red herring. The problem is that the call is made not to the proxy URL but talks to something that expects a WebSocket request.
What did you expect to happen?
Command should work normally.
How can we reproduce it (as minimally and precisely as possible)?
Maybe write a unit test that starts apiserver with a URL path and test how discovery works?
Anything else we need to know?
This is probably related to kubernetes/enhancements#3352, which was released as beta in v1.27.
Kubernetes version
Cloud provider
OS version
Install tools
Container runtime (CRI) and version (if applicable)
Related plugins (CNI, CSI, ...) and versions (if applicable)
The text was updated successfully, but these errors were encountered: