Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Service type=ExternalName is not documented enough #5822
We currently document service types in this doc: https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services---service-types Among these, only 2 types, NodePort and LoadBalancer have their own sections.
Currently all documentation about ExternalName type is listed below. Even this is still not helping me enough to understand what purpose this feature serves, how it can be used (it says proxying is not provided). I think we need a dedicated section to explain this type.
I'm assuming it's a relatively new feature, that's why the comprehensive documentation is lacking.
The whole Services page is a bit of a mess to read and comprehend right now, especially for new users. There is information about system-level choices like kube-proxy to user-level things like DNS, service types, and selectors.
I propose that the content on the current Services page gets reorganized and broken down into these subsections:
If this sounds good, I can take a stab at it.
referenced this issue
Mar 27, 2018
For new users (like me) I think could be common to confuse the purpose of service and ingress.
Until now I don't know if ExternalName could replace the need of nginx-ingress in my on-premises deployment, and wha'ts the scope of ExternalName on-premises.
It is not clear in the documentation what is the best choice to start on-premises (There is better documented choices per cloud provider), probably some wider perspective could be added for on-premises.
For example, until projects like https://metallb.universe.tf/ and nginx-ingress are better documented / mature, is the best option to use the weak NodePort and setup a fixed config reverse-proxy pointing to my node's IPs outside my cluster?
Some documentation with more details and clear explanation like this:
could be very useful for newbies.
@tonglil That's a great suggestion for content structure. For now, I'm going to address the specific issue regarding