Understanding networking | Networking

OKD DNS
OKD Ingress Operator
- Comparing routes and Ingress
Glossary of common terms for OKD networking

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.

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.

OKD DNS

If you are running multiple services, such as front-end and back-end services for use with multiple pods, environment variables are created for user names, service IPs, and more so the front-end pods can communicate with the back-end services. If the service is deleted and recreated, a new IP address can be assigned to the service, and requires the front-end pods to be recreated to pick up the updated values for the service IP environment variable. Additionally, the back-end service must be created before any of the front-end pods to ensure that the service IP is generated properly, and that it can be provided to the front-end pods as an environment variable.

For this reason, OKD has a built-in DNS so that the services can be reached by the service DNS as well as the service IP/port.

OKD Ingress Operator

When you create your OKD cluster, pods and services running on the cluster are each allocated their own IP addresses. The IP addresses are accessible to other pods and services running nearby but are not accessible to outside clients.

The Ingress Operator makes it possible for external clients to access your service by deploying and managing one or more HAProxy-based Ingress Controllers to handle routing. You can use the Ingress Operator to route traffic by specifying OKD Route and Kubernetes Ingress resources. Configurations within the Ingress Controller, such as the ability to define endpointPublishingStrategy type and internal load balancing, provide ways to publish Ingress Controller endpoints.

Comparing routes and Ingress

The Kubernetes Ingress resource in OKD implements the Ingress Controller with a shared router service that runs as a pod inside the cluster. The most common way to manage Ingress traffic is with the Ingress Controller. You can scale and replicate this pod like any other regular pod. This router service is based on HAProxy, which is an open source load balancer solution.

The OKD route provides Ingress traffic to services in the cluster. Routes provide advanced features that might not be supported by standard Kubernetes Ingress Controllers, such as TLS re-encryption, TLS passthrough, and split traffic for blue-green deployments.

Ingress traffic accesses services in the cluster through a route. Routes and Ingress are the main resources for handling Ingress traffic. Ingress provides features similar to a route, such as accepting external requests and delegating them based on the route. However, with Ingress you can only allow certain types of connections: HTTP/2, HTTPS and server name identification (SNI), and TLS with certificate. In OKD, routes are generated to meet the conditions specified by the Ingress resource.

Glossary of common terms for OKD networking

This glossary defines common terms that are used in the networking content.

authentication: To control access to an OKD cluster, a cluster administrator can configure user authentication and ensure only approved users access the cluster. To interact with an OKD cluster, you must authenticate to the OKD API. You can authenticate by providing an OAuth access token or an X.509 client certificate in your requests to the OKD API.
AWS Load Balancer Operator: The AWS Load Balancer (ALB) Operator deploys and manages an instance of the aws-load-balancer-controller.
Cluster Network Operator: The Cluster Network Operator (CNO) deploys and manages the cluster network components in an OKD cluster. This includes deployment of the Container Network Interface (CNI) network plugin selected for the cluster during installation.
config map: A config map provides a way to inject configuration data into pods. You can reference the data stored in a config map in a volume of type ConfigMap. Applications running in a pod can use this data.
custom resource (CR): A CR is extension of the Kubernetes API. You can create custom resources.
DNS: Cluster DNS is a DNS server which serves DNS records for Kubernetes services. Containers started by Kubernetes automatically include this DNS server in their DNS searches.
DNS Operator: The DNS Operator deploys and manages CoreDNS to provide a name resolution service to pods. This enables DNS-based Kubernetes Service discovery in OKD.
deployment: A Kubernetes resource object that maintains the life cycle of an application.
domain: Domain is a DNS name serviced by the Ingress Controller.
egress: The process of data sharing externally through a network’s outbound traffic from a pod.
External DNS Operator: The External DNS Operator deploys and manages ExternalDNS to provide the name resolution for services and routes from the external DNS provider to OKD.
HTTP-based route: An HTTP-based route is an unsecured route that uses the basic HTTP routing protocol and exposes a service on an unsecured application port.
Ingress: The Kubernetes Ingress resource in OKD implements the Ingress Controller with a shared router service that runs as a pod inside the cluster.
Ingress Controller: The Ingress Operator manages Ingress Controllers. Using an Ingress Controller is the most common way to allow external access to an OKD cluster.
installer-provisioned infrastructure: The installation program deploys and configures the infrastructure that the cluster runs on.
kubelet: A primary node agent that runs on each node in the cluster to ensure that containers are running in a pod.
Kubernetes NMState Operator: The Kubernetes NMState Operator provides a Kubernetes API for performing state-driven network configuration across the OKD cluster’s nodes with NMState.
kube-proxy: Kube-proxy is a proxy service which runs on each node and helps in making services available to the external host. It helps in forwarding the request to correct containers and is capable of performing primitive load balancing.
load balancers: OKD uses load balancers for communicating from outside the cluster with services running in the cluster.
MetalLB Operator: As a cluster administrator, you can add the MetalLB Operator to your cluster so that when a service of type LoadBalancer is added to the cluster, MetalLB can add an external IP address for the service.
multicast: With IP multicast, data is broadcast to many IP addresses simultaneously.
namespaces: A namespace isolates specific system resources that are visible to all processes. Inside a namespace, only processes that are members of that namespace can see those resources.
networking: Network information of a OKD cluster.
node: A worker machine in the OKD cluster. A node is either a virtual machine (VM) or a physical machine.
OKD Ingress Operator: The Ingress Operator implements the IngressController API and is the component responsible for enabling external access to OKD services.
pod: One or more containers with shared resources, such as volume and IP addresses, running in your OKD cluster. A pod is the smallest compute unit defined, deployed, and managed.
PTP Operator: The PTP Operator creates and manages the linuxptp services.
route: The OKD route provides Ingress traffic to services in the cluster. Routes provide advanced features that might not be supported by standard Kubernetes Ingress Controllers, such as TLS re-encryption, TLS passthrough, and split traffic for blue-green deployments.
scaling: Increasing or decreasing the resource capacity.
service: Exposes a running application on a set of pods.
Single Root I/O Virtualization (SR-IOV) Network Operator: The Single Root I/O Virtualization (SR-IOV) Network Operator manages the SR-IOV network devices and network attachments in your cluster.
software-defined networking (SDN): OKD uses a software-defined networking (SDN) approach to provide a unified cluster network that enables communication between pods across the OKD cluster.

OpenShift SDN CNI is deprecated as of OKD 4.14. As of OKD 4.15, the network plugin is not an option for new installations. In a subsequent future release, the OpenShift SDN network plugin is planned to be removed and no longer supported. Red Hat will provide bug fixes and support for this feature until it is removed, but this feature will no longer receive enhancements. As an alternative to OpenShift SDN CNI, you can use OVN Kubernetes CNI instead. For more information, see OpenShift SDN CNI removal.

Stream Control Transmission Protocol (SCTP): SCTP is a reliable message based protocol that runs on top of an IP network.
taint: Taints and tolerations ensure that pods are scheduled onto appropriate nodes. You can apply one or more taints on a node.
toleration: You can apply tolerations to pods. Tolerations allow the scheduler to schedule pods with matching taints.
web console: A user interface (UI) to manage OKD.