You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is information missing?
When discussing cluster mode we don't discuss Service type, we do discuss Service type in the NodePort discussion. This point is obvious in that to support NodePort the Service must be in NodePort. We should discuss using headless Services in cluster mode. When using headless Services the Service will not receive a ClusterIP nor will kubeproxy create iptables rules for traffic. The assumption being that if this Service should be a point of ingress, and that traffic will be handled via the BIG-IP, then the user probably doesn't want traffic from other sources - via kubeproxy and the ClusterIP, or even worse possibly via an exposed NodePort.
Add information about headless Services including the reasoning above.
Is a code sample incorrect?
Requests
Provide details regarding what you would like to see added to our documentation:
Environment
Cloud Foundry
Kubernetes
OpenShift
Mesos/Marathon)
Use Case
(i.e., what are you trying to do that you can't find documentation for?)
The text was updated successfully, but these errors were encountered:
Update documentation to recommend headless Service instead of vanilla ClusterIP
// Do not include requests for development or report issues with code or products here.
This repository contains documentation only.
Bugs
Describe the bug in detail:
What doc are you reporting an issue with (provide URL)?
http://clouddocs.f5.com/containers/v2/kubernetes/kctlr-modes.html
What information is inaccurate?
Is information missing?
When discussing cluster mode we don't discuss Service type, we do discuss Service type in the NodePort discussion. This point is obvious in that to support NodePort the Service must be in NodePort. We should discuss using headless Services in cluster mode. When using headless Services the Service will not receive a ClusterIP nor will kubeproxy create iptables rules for traffic. The assumption being that if this Service should be a point of ingress, and that traffic will be handled via the BIG-IP, then the user probably doesn't want traffic from other sources - via kubeproxy and the ClusterIP, or even worse possibly via an exposed NodePort.
Add information about headless Services including the reasoning above.
Requests
Provide details regarding what you would like to see added to our documentation:
Environment
Use Case
(i.e., what are you trying to do that you can't find documentation for?)
The text was updated successfully, but these errors were encountered: