formatting

This commit is contained in:
Marek Biskup 2015-06-16 17:35:07 +02:00
parent 6674913f92
commit b71bf667b5

View File

@ -17,7 +17,7 @@ Enter `Services`.
A Kubernetes `Service` is an abstraction which defines a logical set of `Pods` A Kubernetes `Service` is an abstraction which defines a logical set of `Pods`
and a policy by which to access them - sometimes called a micro-service. The and a policy by which to access them - sometimes called a micro-service. The
set of `Pods` targeted by a `Service` is (usually) determined by a [`Label set of `Pods` targeted by a `Service` is (usually) determined by a [`Label
Selector`](labels.md) (see below for why you might want a `Service` without a Selector`](labels.md#label-selectors) (see below for why you might want a `Service` without a
selector). selector).
As an example, consider an image-processing backend which is running with 3 As an example, consider an image-processing backend which is running with 3
@ -70,13 +70,13 @@ also named "my-service".
Note that a `Service` can map an incoming port to any `targetPort`. By default Note that a `Service` can map an incoming port to any `targetPort`. By default
the `targetPort` is the same as the `port` field. Perhaps more interesting is the `targetPort` is the same as the `port` field. Perhaps more interesting is
that `targetPort` can be a string, referring to the name of a port in the that `targetPort` can be a string, referring to the name of a port in the
backend `Pod`s. The actual port number assigned to that name can be different backend `Pods`. The actual port number assigned to that name can be different
in each backend `Pod`. This offers a lot of flexibility for deploying and in each backend `Pod`. This offers a lot of flexibility for deploying and
evolving your `Service`s. For example, you can change the port number that evolving your `Services`. For example, you can change the port number that
pods expose in the next version of your backend software, without breaking pods expose in the next version of your backend software, without breaking
clients. clients.
Kubernetes `Service`s support `TCP` and `UDP` for protocols. The default Kubernetes `Services` support `TCP` and `UDP` for protocols. The default
is `TCP`. is `TCP`.
### Services without selectors ### Services without selectors
@ -161,12 +161,12 @@ By default, the choice of backend is random. Client-IP based session affinity
can be selected by setting `service.spec.sessionAffinity` to `"ClientIP"` (the can be selected by setting `service.spec.sessionAffinity` to `"ClientIP"` (the
default is `"None"`). default is `"None"`).
As of Kubernetes 1.0, `Service`s are a "layer 3" (TCP/UDP over IP) construct. We do not As of Kubernetes 1.0, `Services` are a "layer 3" (TCP/UDP over IP) construct. We do not
yet have a concept of "layer 7" (HTTP) services. yet have a concept of "layer 7" (HTTP) services.
## Multi-Port Services ## Multi-Port Services
Many `Service`s need to expose more than one port. For this case, Kubernetes Many `Services` need to expose more than one port. For this case, Kubernetes
supports multiple port definitions on a `Service` object. When using multiple supports multiple port definitions on a `Service` object. When using multiple
ports you must give all of your ports names, so that endpoints can be ports you must give all of your ports names, so that endpoints can be
disambiguated. For example: disambiguated. For example:
@ -260,7 +260,8 @@ variables will not be populated. DNS does not have this restriction.
### DNS ### DNS
An optional (though strongly recommended) cluster add-on is a DNS server. The An optional (though strongly recommended) [cluster
add-on](../cluster/add-ons/README.md) is a DNS server. The
DNS server watches the Kubernetes API for new `Services` and creates a set of DNS server watches the Kubernetes API for new `Services` and creates a set of
DNS records for each. If DNS has been enabled throughout the cluster then all DNS records for each. If DNS has been enabled throughout the cluster then all
`Pods` should be able to do name resolution of `Services` automatically. `Pods` should be able to do name resolution of `Services` automatically.
@ -268,11 +269,11 @@ DNS records for each. If DNS has been enabled throughout the cluster then all
For example, if you have a `Service` called "my-service" in Kubernetes For example, if you have a `Service` called "my-service" in Kubernetes
`Namespace` "my-ns" a DNS record for "my-service.my-ns" is created. `Pods` `Namespace` "my-ns" a DNS record for "my-service.my-ns" is created. `Pods`
which exist in the "my-ns" `Namespace` should be able to find it by simply doing which exist in the "my-ns" `Namespace` should be able to find it by simply doing
a name lookup for "my-service". `Pods` which exist in other `Namespace`s must a name lookup for "my-service". `Pods` which exist in other `Namespaces` must
qualify the name as "my-service.my-ns". The result of these name lookups is the qualify the name as "my-service.my-ns". The result of these name lookups is the
cluster IP. cluster IP.
We will soon add DNS support for multi-port `Service`s in the form of SRV We will soon add DNS support for multi-port `Services` in the form of SRV
records. records.
## Headless services ## Headless services
@ -280,10 +281,10 @@ records.
Sometimes you don't need or want load-balancing and a single service IP. In Sometimes you don't need or want load-balancing and a single service IP. In
this case, you can create "headless" services by specifying `"None"` for the this case, you can create "headless" services by specifying `"None"` for the
cluster IP (`spec.clusterIP`). cluster IP (`spec.clusterIP`).
For such `Service`s, a cluster IP is not allocated and service-specific For such `Services`, a cluster IP is not allocated and service-specific
environment variables for `Pod`s are not created. DNS is configured to return environment variables for `Pods` are not created. DNS is configured to return
multiple A records (addresses) for the `Service` name, which point directly to multiple A records (addresses) for the `Service` name, which point directly to
the `Pod`s backing the `Service`. Additionally, the kube proxy does not handle the `Pods` backing the `Service`. Additionally, the kube proxy does not handle
these services and there is no load balancing or proxying done by the platform these services and there is no load balancing or proxying done by the platform
for them. The endpoints controller will still create `Endpoints` records in for them. The endpoints controller will still create `Endpoints` records in
the API. the API.
@ -401,9 +402,9 @@ eliminate userspace proxying in favor of doing it all in iptables. This should
perform better and fix the source-IP obfuscation, though is less flexible than perform better and fix the source-IP obfuscation, though is less flexible than
arbitrary userspace code. arbitrary userspace code.
We intend to have first-class support for L7 (HTTP) `Service`s. We intend to have first-class support for L7 (HTTP) `Services`.
We intend to have more flexible ingress modes for `Service`s which encompass We intend to have more flexible ingress modes for `Services` which encompass
the current `ClusterIP`, `NodePort`, and `LoadBalancer` modes and more. the current `ClusterIP`, `NodePort`, and `LoadBalancer` modes and more.
## The gory details of virtual IPs ## The gory details of virtual IPs
@ -457,7 +458,7 @@ backend, and starts proxying traffic from the client to the backend.
This means that `Service` owners can choose any port they want without risk of This means that `Service` owners can choose any port they want without risk of
collision. Clients can simply connect to an IP and port, without being aware collision. Clients can simply connect to an IP and port, without being aware
of which `Pod`s they are actually accessing. of which `Pods` they are actually accessing.
![Services detailed diagram](services_detail.png) ![Services detailed diagram](services_detail.png)