Fixed some typos:

Changed "an unified" to "a unified"
Changed "a extra" to "an extra"
Changed "for each pod have" to "for each pod to have"
This commit is contained in:
CJ Cullen
2014-08-20 09:49:50 -07:00
parent 0db7989809
commit 4a2c3c8c87
3 changed files with 3 additions and 3 deletions

View File

@@ -6,7 +6,7 @@ Why doesn't Kubernetes just support an affinity mechanism for co-scheduling cont
In addition to defining the containers that run in the pod, the pod specifies a set of shared storage volumes. Pods facilitate data sharing and IPC among their constituents. In the future, they may share CPU and/or memory ([LPC2013](http://www.linuxplumbersconf.org/2013/ocw//system/presentations/1239/original/lmctfy%20(1).pdf)).
The containers in the pod also all use the same network namespace/IP (and port space). The goal is for each pod have an IP address in a flat shared networking namespace that has full communication with other physical computers and containers across the network. [More details on networking](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/networking.md).
The containers in the pod also all use the same network namespace/IP (and port space). The goal is for each pod to have an IP address in a flat shared networking namespace that has full communication with other physical computers and containers across the network. [More details on networking](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/networking.md).
While pods can be used to host vertically integrated application stacks, 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.