Re: [kubernetes/kubernetes] Kubernetes API Server should not depend on --cloud-provider and --cloud-config (#49402)
Brian Grant
I haven't had time to track it closely, but the Plan of Record is to get cloud providers out of tree entirely.
It should be possible to remove this particular dependency using initializers.
cc @kubernetes/sig-storage-bugs
β
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
Clayton Coleman
I believe that work is already in progress - @rrati didn't you have something open for this?
Davanum Srinivas
Thanks @bgrant0607 @smarterclayton
Davanum Srinivas
@smarterclayton @rrati Found it! looks like this one #44680
Lucas KΓ€ldstrΓΆm
@dims Cool that you found it! I was just about to dig it up :)
Chao Xu
cc @cheftako
Davanum Srinivas
More work is being done in #51629
Lucas KΓ€ldstrΓΆm
Also we should talk about if the SSH-to-nodes GCE thingy is really needed anymore with the latest auth features...
@kubernetes/sig-auth-feature-requests
Eric Chiang
@luxas is that involved with the cloud provider? I was under the impression it was just flags on the API server that didn't interact with an external service.
--ssh-keyfile string If non-empty, use secure SSH proxy to the nodes, using this user keyfile
--ssh-user string If non-empty, use secure SSH proxy to the nodes, using this user name
Lucas KΓ€ldstrΓΆm
@ericchiang Now remember, I was thinking about the node dialer talking to the cloud provider re: installing SSH keys: https://github.com/kubernetes/kubernetes/blob/master/cmd/kube-apiserver/app/server.go#L212-L241
Only provider that implements this AddSSHKeyToAllInstances function in the cloudprovider interface is GCE. I'm asking whether this is actually required anymore or if we can deprecate and remove...
Fabian Ruff
@luxas Do you mean removing the ssh tunnelling feature completly or just removing AddSSHKeyToAllInstances from the cloud interface?
Jordan Liggitt
I'd like to see the tunneling feature removed. If a particular deployment topology requires it, I would expect that deployment to set up VPNβstyle tunneling for specific IP ranges, rather than adding complexity throughout the API server
Fabian Ruff
@liggitt Sorry to hear that. I was hoping to build on that feature in out deployment. Setting um vpn tunnels requires more outside machinery and complicates the setup considerably in my case.
Jordan Liggitt
The complication is there regardless of whether it is built into the api server or not, and the tunneling built into the api server is opaque, not as robust as dedicated vpn solutions, and has been repeatedly problematic.
Jago Macleod
@liggitt that seems like a reasonable direction to explore, but needs more discussion, as this is currently supported functionality. Also concerned that this comment will get buried and missed in what was reported as a bug.
Lucas KΓ€ldstrΓΆm
@jagosan Anyway, it's only GCE that's using this. Removing GCE-only code in the core k8s codebase is a general theme anyway in my understanding. As @liggitt said, we don't strictly need this in the core api server.
On this note, kube-up.sh has been deprecated for a long time, and the plan is to move over to using kubeadm eventually. We will have to hack on the way GCE/GKE deploys clusters anyway. And, I'm not sure I see the exact value to have this now that we have better authn/authz mechanisms in core (as compared to before, where this was strictly needed)
Can we deprecate this functionality now, and work out a plan to stop using it in GCE/GKE gradually please?
We can definitely move this to a separate issue...
Jago Macleod
@luxas I am not against the idea, just making the point that this discussion has veered off topic and don't want important discussions to get lost when this issue (reported as a bug with a title that isn't obviously related to the dialer's continued existence) is somehow resolved.
Davanum Srinivas
This is part of larger work - #48690
Davanum Srinivas
How to make progress from @lavalamp - #53912 (comment)
Davanum Srinivas
/priority important-soon
fejta-bot
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Prevent issues from auto-closing with an /lifecycle frozen comment.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale
fejta-bot
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale
fejta-bot
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
k8s-ci-robot
Closed #49402.
Jordan Liggitt
Reopened #49402.
Jordan Liggitt
/remove-lifecycle rotten
fejta-bot
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
fejta-bot
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale
fejta-bot
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
k8s-ci-robot
Closed #49402.
Lucas KΓ€ldstrΓΆm
Reopened #49402.
Lucas KΓ€ldstrΓΆm
This seems to still be relevant I think.
@kubernetes/sig-cloud-provider-bugs any update on this front?
Andrew Sy Kim
Yup we're working through this. I'm not sure we're at a place yet where we can remove that dependency given some providers still depend on it (e.g. AddSSHKeyToAllInstances). I think we're in agreeance that the SSH key feature should be removed (or at least shift responsibility to something that is not "core") but we need to be careful not to break anything. Our main focus right now is #69585, once that's done we should have some action items to tackle this.
Niko Pen
Greetings!
π code freeze π is coming in about 10 days, is this intented to be implemented in the following 2-3 weeks?
@dims @andrewsykim @jagosan @cheftako
Andrew Sy Kim
@nikopen thanks for following up, this won't be in for v1.14.
Niko Pen
/milestone v1.15
Davanum Srinivas
/milestone v1.16
Walter Fender
Removing this flag is reliant on completion of https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190226-network-proxy.md
Josiah Bjorgaard
Since this issue is tagged for milestone v1.16, here is a gentle reminder that code freeze is starting in 9 days on August 29th. Is the issue still targeted for this release?
Davanum Srinivas
/milestone next
Kubernetes Prow Robot
@dims: The provided milestone is not valid for this repository. Milestones in this repository: [next-candidate, v1.10, v1.11, v1.12, v1.13, v1.14, v1.15, v1.16, v1.17, v1.18, v1.4, v1.5, v1.6, v1.7, v1.8, v1.9]
Use /milestone clear to clear the milestone.
In response to this:
/milestone next
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
Marko MudriniΔ
/milestone next-candidate
Andrew Sy Kim
/triage accepted
β
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
Kubernetes Triage Robot
This issue has not been updated in over 1 year, and should be re-triaged.
You can:
- Confirm that this issue is still relevant with
/triage accepted(org members only) - Close this issue with
/close
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/
/remove-triage accepted
β
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
Kubernetes Prow Robot
This issue is currently awaiting triage.
If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.
The triage/accepted label can be added by org members by writing /triage accepted in a comment.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
β
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
David Eads
Since this issue was created, the in-tree cloud provider has been frozen and external cloud controller managers are active. Once the transition is complete we'll be able to remove this. I think the external cloud provider transition will continue with or without this issue and at this point there isn't a clear benefit to transitioning the kube-apiserver early
/close
β
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
Kubernetes Prow Robot
Closed #49402 as completed.
β
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
Kubernetes Prow Robot
@deads2k: Closing this issue.
In response to this:
Since this issue was created, the in-tree cloud provider has been frozen and external cloud controller managers are active. Once the transition is complete we'll be able to remove this. I think the external cloud provider transition will continue with or without this issue and at this point there isn't a clear benefit to transitioning the kube-apiserver early
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
β
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
Federico Bongiovanni
/triage accepted
β
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.