-
Notifications
You must be signed in to change notification settings - Fork 38.8k
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
Service port validation #974
Comments
oops... |
This issue is largely deprecated. Will close with IP per service lands. |
IP-per-service does not eliminate this. Even after ip-per-service, some Services will have to use HostPorts (for External Load Balancer, for now). Much reduced, but that just makes a conflict even less common and harder to debug. It boils down to: both Pods and Services can use HostPorts. We currently check Pods against other Pods for host-port conflicts, but we do not check Pods against Services, nor vice-versa, nor Services against Services. We need some common way for both resource classes to check for conflicts and reserve HostPorts atomically. |
Closing this as it is now obsolete with service v2. |
This is to be addressed in v0.5. |
Closing this, as it is no longer possible for services and pods to have port conflicts, unless a user does something manual (like specify a host IP for the "PublicIP" for a service) |
Godeps: Update glog version.
…rry-pick-959-to-release-4.9 Bug 2006717: etcd-client starts retrying transient errors from the etcd cluster
AFAICT, ValidateService doesn't check that a port is specified. What happens when no port is specified?
I also can't find anywhere where we check that 2 services don't ask for the same port.
Additionally, host ports may conflict with service ports. It would be useful to report such conflicts and to prevent the creation of services that conflict with host ports and vice versa.
The text was updated successfully, but these errors were encountered: