mirror of
https://github.com/k3s-io/kubernetes.git
synced 2025-08-04 01:40:07 +00:00
add blank line before list; do s/-/*/ for list-element prefix
This commit is contained in:
parent
9597e64945
commit
c744b99c45
21
docs/pods.md
21
docs/pods.md
@ -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
|
||||||
|
Loading…
Reference in New Issue
Block a user