whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update service.md

Browse Source
This commit is contained in:
stewart-yu
2017-11-23 14:56:06 +08:00
committed by Jared
parent 03eb37c54e
commit ef8908fbb1
1 changed files with 25 additions and 31 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/concepts/services-networking/service.md
+25 -31
View File
@@ -117,7 +117,7 @@ subsets:
- port: 9376 - port: 9376
``` ```
NOTE: Endpoint IPs may not be loopback (127.0.0.0/8), link-local **NOTE:** Endpoint IPs may not be loopback (127.0.0.0/8), link-local
(169.254.0.0/16), or link-local multicast (224.0.0.0/24). (169.254.0.0/16), or link-local multicast (224.0.0.0/24).
Accessing a `Service` without a selector works the same as if it had a selector. Accessing a `Service` without a selector works the same as if it had a selector.
@@ -151,13 +151,11 @@ its pods, add appropriate selectors or endpoints and change the service `type`.
Every node in a Kubernetes cluster runs a `kube-proxy`. `kube-proxy` is Every node in a Kubernetes cluster runs a `kube-proxy`. `kube-proxy` is
responsible for implementing a form of virtual IP for `Services` of type other responsible for implementing a form of virtual IP for `Services` of type other
than `ExternalName`. than `ExternalName`.
In Kubernetes v1.0 the proxy was purely in userspace. In Kubernetes v1.1 an In Kubernetes v1.0, `Services` are a "layer 4" (TCP/UDP over IP) construct, the
iptables proxy was added, but was not the default operating mode. Since proxy was purely in userspace. In Kubernetes v1.1, the `Ingress` API was added
Kubernetes v1.2, the iptables proxy is the default. (beta) to represent "layer 7"(HTTP) services, iptables proxy was added too,
and become the default operating mode since Kubernetes v1.2. In Kubernetes v1.9-alpha,
As of Kubernetes v1.0, `Services` are a "layer 4" (TCP/UDP over IP) construct. ipvs proxy was added.
In Kubernetes v1.1 the `Ingress` API was added (beta) to represent "layer 7"
(HTTP) services.
### Proxy-mode: userspace ### Proxy-mode: userspace
@@ -169,37 +167,20 @@ will be proxied to one of the `Service`'s backend `Pods` (as reported in
`SessionAffinity` of the `Service`. Lastly, it installs iptables rules which `SessionAffinity` of the `Service`. Lastly, it installs iptables rules which
capture traffic to the `Service`'s `clusterIP` (which is virtual) and `Port` capture traffic to the `Service`'s `clusterIP` (which is virtual) and `Port`
and redirects that traffic to the proxy port which proxies the backend `Pod`. and redirects that traffic to the proxy port which proxies the backend `Pod`.
By default, the choice of backend is round robin.
The net result is that any traffic bound for the `Service`'s IP:Port is proxied
to an appropriate backend without the clients knowing anything about Kubernetes
or `Services` or `Pods`.
By default, the choice of backend is round robin. Client-IP based session affinity
can be selected by setting `service.spec.sessionAffinity` to `"ClientIP"` (the
default is `"None"`), and you can set the max session sticky time by setting the field
`service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` if you have already set
`service.spec.sessionAffinity` to `"ClientIP"` (the default is "10800").
![Services overview diagram for userspace proxy](/images/docs/services-userspace-overview.svg) ![Services overview diagram for userspace proxy](/images/docs/services-userspace-overview.svg)
### Proxy-mode: iptables ### Proxy-mode: iptables
In this mode, kube-proxy watches the Kubernetes master for the addition and In this mode, kube-proxy watches the Kubernetes master for the addition and
removal of `Service` and `Endpoints` objects. For each `Service` it installs removal of `Service` and `Endpoints` objects. For each `Service`, it installs
iptables rules which capture traffic to the `Service`'s `clusterIP` (which is iptables rules which capture traffic to the `Service`'s `clusterIP` (which is
virtual) and `Port` and redirects that traffic to one of the `Service`'s virtual) and `Port` and redirects that traffic to one of the `Service`'s
backend sets. For each `Endpoints` object it installs iptables rules which backend sets. For each `Endpoints` object, it installs iptables rules which
select a backend `Pod`. select a backend `Pod`.By default, the choice of backend is random.
By default, the choice of backend is random. Client-IP based session affinity Obviously, iptables need not switch back between userspace and kernelspace, it should be
can be selected by setting `service.spec.sessionAffinity` to `"ClientIP"` (the
default is `"None"`), and you can set the max session sticky time by setting the field
`service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` if you have already set
`service.spec.sessionAffinity` to `"ClientIP"` (the default is "10800").
As with the userspace proxy, the net result is that any traffic bound for the
`Service`'s IP:Port is proxied to an appropriate backend without the clients
knowing anything about Kubernetes or `Services` or `Pods`. This should be
faster and more reliable than the userspace proxy. However, unlike the faster and more reliable than the userspace proxy. However, unlike the
userspace proxier, the iptables proxier cannot automatically retry another userspace proxier, the iptables proxier cannot automatically retry another
`Pod` if the one it initially selects does not respond, so it depends on `Pod` if the one it initially selects does not respond, so it depends on
@@ -231,12 +212,21 @@ options for load balancing algorithm, such as:
- nq: never queue - nq: never queue
**Note:** ipvs mode assumed IPVS kernel modules are installed on the node **Note:** ipvs mode assumed IPVS kernel modules are installed on the node
before running kube-proxy. When kube-proxy starts, if proxy mode is ipvs, before running kube-proxy. When kube-proxy starts with ipvs proxy mode,
kube-proxy would validate if IPVS modules are installed on the node, if kube-proxy would validate if IPVS modules are installed on the node, if
it's not installed kube-proxy will fall back to iptables proxy mode. it's not installed kube-proxy will fall back to iptables proxy mode.
![Services overview diagram for ipvs proxy](/images/docs/services-ipvs-overview.svg) ![Services overview diagram for ipvs proxy](/images/docs/services-ipvs-overview.svg)
In any of proxy model, any traffic bound for the Service’s IP:Port is
proxied to an appropriate backend without the clients knowing anything
about Kubernetes or Services or Pods. Client-IP based session affinity
can be selected by setting service.spec.sessionAffinity to "ClientIP"
(the default is "None"), and you can set the max session sticky time by
setting the field service.spec.sessionAffinityConfig.clientIP.timeoutSeconds
if you have already set service.spec.sessionAffinity to "ClientIP"
(the default is “10800”).
## Multi-Port Services ## Multi-Port Services
Many `Services` need to expose more than one port. For this case, Kubernetes Many `Services` need to expose more than one port. For this case, Kubernetes
@@ -708,6 +698,10 @@ work, and the client IP is not altered.
This same basic flow executes when traffic comes in through a node-port or This same basic flow executes when traffic comes in through a node-port or
through a load-balancer, though in those cases the client IP does get altered. through a load-balancer, though in those cases the client IP does get altered.
#### Ipvs
Iptables operations slow down dramatically in large scale cluster e.g 10,000 Services. IPVS is designed for load balancing and based on in-kernel hash tables. So we can achieve performance consistency in large number of services from IPVS-based kube-proxy. Meanwhile, IPVS-based kube-proxy has more sophisticated load balancing algorithms (least conns, locality, weighted, persistence).
## API Object ## API Object
Service is a top-level resource in the Kubernetes REST API. More details about the Service is a top-level resource in the Kubernetes REST API. More details about the