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

migrate the K8s networking model section (#28617)

Browse Source
This commit is contained in:
Neha Viswanathan
2022-01-05 08:08:41 -08:00
committed by GitHub
parent 14671be579
commit 24ee2527d0
2 changed files with 46 additions and 52 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/cluster-administration/networking.md
+1 -49
View File
@@ -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
content/en/docs/concepts/services-networking/_index.md
+45 -3
View File
@@ -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/).