Closed erikbgithub closed 5 years ago
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
/remove-lifecycle stale /lifecycle frozen
@sftim Will #14526 address this? If not, can I work on this?
PR #14526 will help, I hope. There's yet more to do afterwards. I think the main page about the Service concept should talk less about implementation details like AWS load balancers, and more about different ways of handling ingress (eg Ingress, Istio, Gloo).
Because #14526 is a big set of changes, I think it makes sense to build on it once merged.
@palnabarun you could sketch out (in your mind, on paper, using Git, whatever) what that documentation might look like in the future, even before #14526 is ready to merge. Does that sound alright?
/language en
@sftim Sure. I would make a note of it.
What I felt is, right now as a temporary measure we can add the reference to Ingress
and Ingress Controller
in the Service
documentation so that readers get pointed to the right direction and learn more about it.
How about closing this in favor of #14770?
Sure. We can track about refactoring the Service documentation on #14770
/assign /close
@sethmccombs: Closing this issue.
This is a...
Problem: The linked page (also here) describes external access to internal services via NodePort. But when I talk to people who really know Kubernetes well they always suggest to externalize services via Ingress. Without this info at the NodePort spot newcomers stop after reading about NodePorts and don't even get to the Ingress page. I mean, who reads the whole manual when one's questions are already (seemingly) answered, right?
Proposed Solution: The page should mention Ingress, and probably how the Kubernetes stands to the NodePort vs Ingress question. My guess would be that more and more people want Ingresses instead of NodePorts, because they seem to also support other features that is required with externalization like Loadbalancing (which you don't have automatically in bare metal installations).
Page to Update: https://kubernetes.io/docs/concepts/services-networking/service/