Methods for Managing Ingress Traffic

OKD provides different methods for managing ingress traffic. The parenthesis indicates whether this is a service type or a resource.

Ingress (resource)

The Ingress Operator manages this resource. Ingresses accept external requests and proxy them based on the route. You can only route HTTP, HTTPS and server name identification (SNI), and TLS with SNI.

An Ingress is a Kubernetes resource that provides some of the same features as routes (which are an OKD resource), but also includes specific features, such as path-based routing, TLS re-encryption, or support of wildcard domains.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
    name: example
    namespace: network-ingress
spec:
    rules:
        - host: frontend.apps.acme.com
          http:
            paths:
        - path: /testpath
          backend:
          serviceName: test
          servicePort: 80
External load balancer (service type)

This resources instructs OKD to spin up a load balancer in a cloud environment. A load balancer instructs OKD to interact with the cloud provider in which the cluster is running to provision a load balancer.

Service external IP (service type)

This method instructs OKD to set NAT rules to redirect traffic from one of the cluster IPs to the container.

NodePort (service type)

With this method, OKD exposes a service on a static port on the node IP address. You must ensure that the external IP addresses are properly routed to the nodes.

OpenShift ingresses and routes are implemented by a shared router service that runs as a pod inside the cluster. You can scale and replicate this pod like any other regular pod. This router service is based on the open source software HAProxy.

An important consideration for OKD administrators is that the public DNS hostnames configured for routes must point to the public-facing IP addresses of the nodes running the router.

Router pods, unlike regular application pods, bind to public IP addresses of the nodes, instead of to the internal pod network. This is typically configured using a DNS wildcard.

You must provide the following value when creating a route:

  • The name of a service. The route uses the service to determine the pods to which to route the traffic.
  • A host name for the route. A route is always a subdomain of your cluster wildcard domain. For example, if you are using a wildcard domain of apps.dev-cluster.acme.com, and need to expose a front-end service through a route, then it will be named:
frontend.apps.dev-cluster.acme.com
  • An optional path, for path-based routes.
  • A target port, which is the port on which the application listens. The target port usually corresponds to the port that you define in the targetPort key of a service.
  • An encryption strategy, depending on whether you need a secure or insecure route
Daftar Materi