From 99913aae2f47abf7ee7542b665cdc0e27ec8cf7d Mon Sep 17 00:00:00 2001 From: Neha Viswanathan Date: Thu, 24 Jun 2021 22:26:57 -0700 Subject: [PATCH] migrate the K8s networking model section --- .../cluster-administration/networking.md | 42 +------------------ .../concepts/services-networking/_index.md | 42 +++++++++++++++++++ 2 files changed, 44 insertions(+), 40 deletions(-) diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md index c517b13175c81..c9f80de3f3379 100644 --- a/content/en/docs/concepts/cluster-administration/networking.md +++ b/content/en/docs/concepts/cluster-administration/networking.md @@ -30,46 +30,8 @@ insert dynamic port numbers into configuration blocks, services have to know how to find each other, etc. Rather than deal with this, Kubernetes takes a different approach. -## The Kubernetes network model - -Every `Pod` gets its own 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, -application configuration, and migration. - -Kubernetes imposes the following fundamental requirements on any networking -implementation (barring any intentional network segmentation policies): - - * pods on a node can communicate with all pods on all 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 - -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 -to containers. If your job previously ran in a VM, your VM had an IP and could -talk to other VMs in your project. This is the same basic model. - -Kubernetes IP addresses exist at the `Pod` scope - containers within a `Pod` -share their network namespaces - including their IP address and MAC address. -This means that containers within a `Pod` can all reach each other's ports on -`localhost`. This also means that containers within a `Pod` must coordinate port -usage, but this is no different from processes in a VM. This is called the -"IP-per-pod" model. - -How this is implemented is a detail of the particular container runtime in use. - -It is possible to request ports on the `Node` itself which forward to your `Pod` -(called host ports), but this is a very niche operation. How that forwarding is -implemented is also a detail of the container runtime. The `Pod` itself is -blind to the existence or non-existence of host ports. +To learn about the Kubernetes networking model, see [here](/docs/concepts/services-networking/_index.md). + ## How to implement the Kubernetes networking model diff --git a/content/en/docs/concepts/services-networking/_index.md b/content/en/docs/concepts/services-networking/_index.md index 2e7d91427e6c6..b4e7d03e7f911 100644 --- a/content/en/docs/concepts/services-networking/_index.md +++ b/content/en/docs/concepts/services-networking/_index.md @@ -5,6 +5,48 @@ description: > Concepts and resources behind networking in Kubernetes. --- +## The Kubernetes network model + +Every `Pod` gets its own 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, +application configuration, and migration. + +Kubernetes imposes the following fundamental requirements on any networking +implementation (barring any intentional network segmentation policies): + + * pods on a node can communicate with all pods on all 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 + +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 +to containers. If your job previously ran in a VM, your VM had an IP and could +talk to other VMs in your project. This is the same basic model. + +Kubernetes IP addresses exist at the `Pod` scope - containers within a `Pod` +share their network namespaces - including their IP address and MAC address. +This means that containers within a `Pod` can all reach each other's ports on +`localhost`. This also means that containers within a `Pod` must coordinate port +usage, but this is no different from processes in a VM. This is called the +"IP-per-pod" model. + +How this is implemented is a detail of the particular container runtime in use. + +It is possible to request ports on the `Node` itself which forward to your `Pod` +(called host ports), but this is a very niche operation. How that forwarding is +implemented is also a detail of the container runtime. The `Pod` itself is +blind to the existence or non-existence of host ports. + + Kubernetes networking addresses four concerns: - Containers within a Pod use networking to communicate via loopback. - Cluster networking provides communication between different Pods.