mirror of
				https://github.com/k3s-io/kubernetes.git
				synced 2025-11-03 23:40:03 +00:00 
			
		
		
		
	add blank line before list; do s/-/*/ for list-element prefix
This commit is contained in:
		
							
								
								
									
										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
 | 
				
			||||||
 
 | 
				
			|||||||
		Reference in New Issue
	
	Block a user