diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md index fb34a82d50e08..ee7793d004600 100644 --- a/content/en/docs/concepts/cluster-administration/networking.md +++ b/content/en/docs/concepts/cluster-administration/networking.md @@ -30,55 +30,7 @@ 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, maximum one per IP family. This means you -do not need need to deal with mapping container ports to host ports in order to -expose the `Pods` services on the network. 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 IP addresses exist at the `Pod` scope, in the `status.PodIPs` field -- containers within a `Pod` share their network namespaces - including their IP -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. - -In every cluster, there exists an abstract pod-network to which pods -are connected by default, unless explicitly configured to use the -host-network (on platforms that support it). Even if a host has -multiple IPs, host-network pods only have one Kubernetes IP address at -the `Pod` scope, that is, the `status.PodIPs` field contains one -IP per address family (for now), so the "IP-per-pod" model is guaranteed. - -Kubernetes imposes the following fundamental requirements on any networking -implementation (barring any intentional network segmentation policies): - - * any pod-network pod on any node can communicate with all other pod-network - pods on all nodes without NAT. - * non-pod processes on a node (the kubelet, and also for example any other system daemon) can - communicate with all pods on that node. - -In addition, for platforms and runtimes that support running pods in the host OS network: - - * host-network pods of a node can connect directly with all pods IPs on all - nodes, however, unlike pod-network pods, the source IP address might not be - present in the `Pod` `status.PodIPs` field. - -This model is principally compatible with the desire for Kubernetes to enable -low-friction porting of apps from VMs to containers. If your workload previously ran -in a VM, your VM typically had a single IP address; everything in that VM could talk to -other VMs on your network. -This is the same basic model but less complex overall. - -How this is implemented is a detail of the particular container runtime in use. Likewise, the networking option you choose may support [dual-stack IPv4/IPv6 networking](/docs/concepts/services-networking/dual-stack/); implementations vary. - -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/). ## 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..ab1b784658bb8 100644 --- a/content/en/docs/concepts/services-networking/_index.md +++ b/content/en/docs/concepts/services-networking/_index.md @@ -5,8 +5,50 @@ description: > Concepts and resources behind networking in Kubernetes. --- +## The Kubernetes network model + +Every [`Pod`](/docs/concepts/workloads/pods/) 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](/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 + * 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. +- Containers within a Pod [use networking to communicate](/docs/concepts/services-networking/dns-pod-service/) via loopback. - Cluster networking provides communication between different Pods. -- The Service resource lets you expose an application running in Pods to be reachable from outside your cluster. -- You can also use Services to publish services only for consumption inside your cluster. +- The [Service resource](/docs/concepts/services-networking/service/) lets you [expose an application running in Pods](/docs/concepts/services-networking/connect-applications-service/) to be reachable from outside your cluster. +- You can also use Services to [publish services only for consumption inside your cluster](/docs/concepts/services-networking/service-traffic-policy/).