@@ -7,26 +7,25 @@ description: >
7
7
8
8
## The Kubernetes network model
9
9
10
- Every [ ` Pod ` ] ( /docs/concepts/workloads/pods/ ) gets its own IP address.
10
+ Every [ ` Pod ` ] ( /docs/concepts/workloads/pods/ ) in a cluster gets its own unique cluster-wide IP address.
11
11
This means you do not need to explicitly create links between ` Pods ` and you
12
12
almost never need to deal with mapping container ports to host ports.
13
13
This creates a clean, backwards-compatible model where ` Pods ` can be treated
14
14
much like VMs or physical hosts from the perspectives of port allocation,
15
- naming, service discovery, [ load balancing] ( /docs/concepts/services-networking/ingress/#load-balancing ) , application configuration,
16
- and migration.
15
+ naming, service discovery, [ load balancing] ( /docs/concepts/services-networking/ingress/#load-balancing ) ,
16
+ application configuration, and migration.
17
17
18
18
Kubernetes imposes the following fundamental requirements on any networking
19
19
implementation (barring any intentional network segmentation policies):
20
20
21
- * pods on a [ node] ( /docs/concepts/architecture/nodes/ ) can communicate with all pods on all nodes without NAT
21
+ * pods can communicate with all other pods on any other [ node] ( /docs/concepts/architecture/nodes/ )
22
+ without NAT
22
23
* agents on a node (e.g. system daemons, kubelet) can communicate with all
23
24
pods on that node
24
25
25
26
Note: For those platforms that support ` Pods ` running in the host network (e.g.
26
- Linux):
27
-
28
- * pods in the host network of a node can communicate with all pods on all
29
- nodes without NAT
27
+ Linux), when pods are attached to the host network of a node they can still communicate
28
+ with all pods on all nodes without NAT.
30
29
31
30
This model is not only less complex overall, but it is principally compatible
32
31
with the desire for Kubernetes to enable low-friction porting of apps from VMs
0 commit comments