Understanding networking

    • Service types, such as node ports or load balancers

    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.

    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.

    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 implements the IngressController API and is the component responsible for enabling external access to OKD cluster services.

    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 type and internal load balancing, provide ways to publish Ingress Controller endpoints.

    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.

    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.

    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

    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 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.

    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.