From fdfc64e861e36fbe6e28f3801bca84c2b54d6ab6 Mon Sep 17 00:00:00 2001 From: sgpinkus Date: Sat, 19 Mar 2022 13:17:50 +1100 Subject: [PATCH 1/2] Update _index.md Make 100% clear, that according to the k8s networking model pods are supposed to get their own unique IP address. I always thought this was the case. But then faced debugging issue where some pods are being assigned the same IP addresses. Came here to review my understanding of it, and confirm this is expected behaviour or not. But it was not stated unequivocally. This change makes it so. --- .../docs/concepts/services-networking/_index.md | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/content/en/docs/concepts/services-networking/_index.md b/content/en/docs/concepts/services-networking/_index.md index ab1b784658..2e443d4744 100644 --- a/content/en/docs/concepts/services-networking/_index.md +++ b/content/en/docs/concepts/services-networking/_index.md @@ -7,26 +7,25 @@ description: > ## The Kubernetes network model -Every [`Pod`](/docs/concepts/workloads/pods/) gets its own IP address. +Every [`Pod`](/docs/concepts/workloads/pods/) in a cluster gets its own unique cluster wide IP address. This means you do not need to explicitly create links between `Pods` and you almost never need to deal with mapping container ports to host ports. This creates a clean, backwards-compatible model where `Pods` can be treated much like VMs or physical hosts from the perspectives of port allocation, -naming, service discovery, [load balancing](/docs/concepts/services-networking/ingress/#load-balancing), application configuration, -and migration. +naming, service discovery, [load balancing](/docs/concepts/services-networking/ingress/#load-balancing), +application configuration, and migration. Kubernetes imposes the following fundamental requirements on any networking implementation (barring any intentional network segmentation policies): - * pods on a [node](/docs/concepts/architecture/nodes/) can communicate with all pods on all nodes without NAT + * pods can communicate with all other pods on any other [node](/docs/concepts/architecture/nodes/) + without NAT * agents on a node (e.g. system daemons, kubelet) can communicate with all pods on that node Note: For those platforms that support `Pods` running in the host network (e.g. -Linux): - - * pods in the host network of a node can communicate with all pods on all - nodes without NAT +Linux), when pods are attached to the host network of a node they can still communicate +with all pods on all nodes without NAT. This model is not only less complex overall, but it is principally compatible with the desire for Kubernetes to enable low-friction porting of apps from VMs From 417eede9858a94fc8f2dec5cf03b7e7cd7566229 Mon Sep 17 00:00:00 2001 From: sgpinkus Date: Mon, 21 Mar 2022 21:01:49 +1100 Subject: [PATCH 2/2] Update content/en/docs/concepts/services-networking/_index.md Co-authored-by: divya-mohan0209 --- content/en/docs/concepts/services-networking/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/services-networking/_index.md b/content/en/docs/concepts/services-networking/_index.md index 2e443d4744..b4f7861075 100644 --- a/content/en/docs/concepts/services-networking/_index.md +++ b/content/en/docs/concepts/services-networking/_index.md @@ -7,7 +7,7 @@ description: > ## The Kubernetes network model -Every [`Pod`](/docs/concepts/workloads/pods/) in a cluster gets its own unique cluster wide IP address. +Every [`Pod`](/docs/concepts/workloads/pods/) in a cluster gets its own unique cluster-wide IP address. This means you do not need to explicitly create links between `Pods` and you almost never need to deal with mapping container ports to host ports. This creates a clean, backwards-compatible model where `Pods` can be treated