Skip to content
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.

Sign up for GitHub

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

Jump to bottom

update service&endpoint describe #14707

Merged
merged 1 commit into from
Sep 30, 2015
Merged

update service&endpoint describe #14707

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
8 changes: 4 additions & 4 deletions docs/user-guide/services.md
View file
Open in desktop
Expand Up @@ -208,11 +208,11 @@ this example).
Every node in a Kubernetes cluster runs a `kube-proxy`. This application
watches the Kubernetes master for the addition and removal of `Service`
and `Endpoints` objects. For each `Service` it opens a port (randomly chosen)
on the local node. Any connections made to that port will be proxied to one of
the corresponding backend `Pods`. Which backend to use is decided based on the
on the local node. Any connections to `service` port will be proxied to one of
the corresponding backend `Pods`. Which backend `Pod` to use is decided based on the
`SessionAffinity` of the `Service`. Lastly, it installs iptables rules which
capture traffic to the `Service`'s cluster IP (which is virtual) and `Port` and
redirects that traffic to the previously described port.
capture traffic to the `Service`'s cluster IP (which is virtual) and `Port` then
redirects that traffic to the backend `Pod` (`Endpoints`).

The net result is that any traffic bound for the `Service` is proxied to an
appropriate backend without the clients knowing anything about Kubernetes or
Expand Down