add blank line before list; do s/-/*/ for list-element prefix

This commit is contained in:
Thien-Thi Nguyen 2015-06-01 07:40:41 +02:00
parent 9597e64945
commit c744b99c45

View File

@ -7,10 +7,11 @@ In Kubernetes, rather than individual application containers, _pods_ are the sma
A _pod_ (as in a pod of whales or pea pod) corresponds to a colocated group of applications running with a shared context. Within that context, the applications may also have individual cgroup isolations applied. A pod models an application-specific "logical host" in a containerized environment. It may contain one or more applications which are relatively tightly coupled -- in a pre-container world, they would have executed on the same physical or virtual host. A _pod_ (as in a pod of whales or pea pod) corresponds to a colocated group of applications running with a shared context. Within that context, the applications may also have individual cgroup isolations applied. A pod models an application-specific "logical host" in a containerized environment. It may contain one or more applications which are relatively tightly coupled -- in a pre-container world, they would have executed on the same physical or virtual host.
The context of the pod can be defined as the conjunction of several Linux namespaces: The context of the pod can be defined as the conjunction of several Linux namespaces:
- PID namespace (applications within the pod can see each other's processes)
- network namespace (applications within the pod have access to the same IP and port space) * PID namespace (applications within the pod can see each other's processes)
- IPC namespace (applications within the pod can use SystemV IPC or POSIX message queues to communicate) * network namespace (applications within the pod have access to the same IP and port space)
- UTS namespace (applications within the pod share a hostname) * IPC namespace (applications within the pod can use SystemV IPC or POSIX message queues to communicate)
* UTS namespace (applications within the pod share a hostname)
Applications within a pod also have access to shared volumes, which are defined at the pod level and made available in each application's filesystem. Additionally, a pod may define top-level cgroup isolations which form an outer bound to any individual isolation applied to constituent applications. Applications within a pod also have access to shared volumes, which are defined at the pod level and made available in each application's filesystem. Additionally, a pod may define top-level cgroup isolations which form an outer bound to any individual isolation applied to constituent applications.
@ -35,11 +36,12 @@ Pods also simplify application deployment and management by providing a higher-l
## Uses of pods ## Uses of pods
Pods can be used to host vertically integrated application stacks, but their primary motivation is to support co-located, co-managed helper programs, such as: Pods can be used to host vertically integrated application stacks, but their primary motivation is to support co-located, co-managed helper programs, such as:
- content management systems, file and data loaders, local cache managers, etc.
- log and checkpoint backup, compression, rotation, snapshotting, etc. * content management systems, file and data loaders, local cache managers, etc.
- data change watchers, log tailers, logging and monitoring adapters, event publishers, etc. * log and checkpoint backup, compression, rotation, snapshotting, etc.
- proxies, bridges, and adapters * data change watchers, log tailers, logging and monitoring adapters, event publishers, etc.
- controllers, managers, configurators, and updaters * proxies, bridges, and adapters
* controllers, managers, configurators, and updaters
Individual pods are not intended to run multiple instances of the same application, in general. Individual pods are not intended to run multiple instances of the same application, in general.
@ -65,6 +67,7 @@ In general, users shouldn't need to create pods directly. They should almost alw
The use of collective APIs as the primary user-facing primitive is relatively common among cluster scheduling systems, including [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/configuration-reference/#job-schema), and [Tupperware](http://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997). The use of collective APIs as the primary user-facing primitive is relatively common among cluster scheduling systems, including [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/configuration-reference/#job-schema), and [Tupperware](http://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997).
Pod is exposed as a primitive in order to facilitate: Pod is exposed as a primitive in order to facilitate:
* scheduler and controller pluggability * scheduler and controller pluggability
* support for pod-level operations without the need to "proxy" them via controller APIs * support for pod-level operations without the need to "proxy" them via controller APIs
* decoupling of pod lifetime from controller lifetime, such as for bootstrapping * decoupling of pod lifetime from controller lifetime, such as for bootstrapping