mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
29 lines
1.6 KiB
Plaintext
29 lines
1.6 KiB
Plaintext
:_mod-docs-content-type: ASSEMBLY
|
|
[id="understanding-networking"]
|
|
= Understanding networking
|
|
include::_attributes/common-attributes.adoc[]
|
|
:context: understanding-networking
|
|
|
|
toc::[]
|
|
Cluster Administrators have several options for exposing applications that run inside a cluster to external traffic and securing network connections:
|
|
|
|
* Service types, such as node ports or load balancers
|
|
|
|
* API resources, such as `Ingress` and `Route`
|
|
|
|
By default, Kubernetes allocates each pod an internal IP address for applications running within the pod. Pods and their containers can network, but clients outside the cluster do not have networking access. When you expose your application to external traffic, giving each pod its own IP address means that pods can be treated like physical hosts or virtual machines in terms of port allocation, networking, naming, service discovery, load balancing, application configuration, and migration.
|
|
|
|
[NOTE]
|
|
====
|
|
Some cloud platforms offer metadata APIs that listen on the 169.254.169.254 IP address, a link-local IP address in the IPv4 `169.254.0.0/16` CIDR block.
|
|
|
|
This CIDR block is not reachable from the pod network. Pods that need access to these IP addresses must be given host network access by setting the `spec.hostNetwork` field in the pod spec to `true`.
|
|
|
|
If you allow a pod host network access, you grant the pod privileged access to the underlying network infrastructure.
|
|
====
|
|
|
|
include::modules/nw-ne-openshift-dns.adoc[leveloffset=+1]
|
|
include::modules/nw-ne-openshift-ingress.adoc[leveloffset=+1]
|
|
include::modules/nw-ne-comparing-ingress-route.adoc[leveloffset=+2]
|
|
include::modules/nw-networking-glossary-terms.adoc[leveloffset=+1]
|