whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix grammar in docker networking description (#7295)

Browse Source
This commit is contained in:
juimonen
2018-02-13 01:29:49 +02:00
committed by k8s-ci-robot
parent ba65eb7152
commit 1fd07dd1e8
2 changed files with 6 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/concepts/cluster-administration/networking.md
+5 -5
View File
@@ -47,11 +47,11 @@ are on the same machine (and thus the same virtual bridge). Containers on
different machines can not reach each other - in fact they may end up with the different machines can not reach each other - in fact they may end up with the
exact same network ranges and IP addresses. exact same network ranges and IP addresses.
In order for Docker containers to communicate across nodes, they must be In order for Docker containers to communicate across nodes, there must
allocated ports on the machine's own IP address, which are then forwarded or be allocated ports on the machine’s own IP address, which are then
proxied to the containers. This obviously means that containers must either forwarded or proxied to the containers. This obviously means that
coordinate which ports they use very carefully or else be allocated ports containers must either coordinate which ports they use very carefully
dynamically. or ports must be allocated dynamically.
## Kubernetes model ## Kubernetes model
docs/concepts/services-networking/connect-applications-service.md
+1 -1
View File
@@ -13,7 +13,7 @@ title: Connecting Applications with Services
Now that you have a continuously running, replicated application you can expose it on a network. Before discussing the Kubernetes approach to networking, it is worthwhile to contrast it with the "normal" way networking works with Docker. Now that you have a continuously running, replicated application you can expose it on a network. Before discussing the Kubernetes approach to networking, it is worthwhile to contrast it with the "normal" way networking works with Docker.
By default, Docker uses host-private networking, so containers can talk to other containers only if they are on the same machine. In order for Docker containers to communicate across nodes, they must be allocated ports on the machine's own IP address, which are then forwarded or proxied to the containers. This obviously means that containers must either coordinate which ports they use very carefully or else be allocated ports dynamically. By default, Docker uses host-private networking, so containers can talk to other containers only if they are on the same machine. In order for Docker containers to communicate across nodes, there must be allocated ports on the machine’s own IP address, which are then forwarded or proxied to the containers. This obviously means that containers must either coordinate which ports they use very carefully or ports must be allocated dynamically.
Coordinating ports across multiple developers is very difficult to do at scale and exposes users to cluster-level issues outside of their control. Kubernetes assumes that pods can communicate with other pods, regardless of which host they land on. We give every pod its own cluster-private-IP address so you do not need to explicitly create links between pods or mapping container ports to host ports. This means that containers within a Pod can all reach each other's ports on localhost, and all pods in a cluster can see each other without NAT. The rest of this document will elaborate on how you can run reliable services on such a networking model. Coordinating ports across multiple developers is very difficult to do at scale and exposes users to cluster-level issues outside of their control. Kubernetes assumes that pods can communicate with other pods, regardless of which host they land on. We give every pod its own cluster-private-IP address so you do not need to explicitly create links between pods or mapping container ports to host ports. This means that containers within a Pod can all reach each other's ports on localhost, and all pods in a cluster can see each other without NAT. The rest of this document will elaborate on how you can run reliable services on such a networking model.