back to Home or Openshift

Overview

Openshift provides a number of means to access the cluster for different protocols including

  • router
  • Load Balancer
  • ExternalIP
  • NodePort.

for

  • HTTP/HTTPS, use the router.
  • TLS-encrypted protocol other than HTTPS (for example, TLS with the SNI header), use the router.
  • Otherwise, use Load Balancer, ExternalIP, or NodePort.

External Access Mechanisms

Router

The most common way to access the Cluster which supports HTTP/HTTPS(SNI)/TLS(SNI), which covers web applications.

Setup:

  • An administrator can create a wildcard DNS entry, and then set up a router
  • Users can self-service the edge router without having to contact the administrators.

Load Balancer Service

Load balancers are available on AWS and GCE clouds, and non-cloud options are also available.

Non-cloud load balancer allocates a unique IP from a configured pool. This has some limits

  • limited to a single edge router IP, which can be a VIP, but still will be a single machine for initial load balancing.

Service ExternalIP

  • Administrators can assign a list of externalIPs, for which nodes in the cluster will also accept traffic for the service.

Ingress IP Self-Service

Ingress IP Self-Service streamlines the allocation of External IPs for accessing services in the cluster.

Cluster administrators can designate a range of addresses using a CIDR notation

When an Openshift Service is configured with the type LoadBalancer, an External IP address will be automatically assigned from the designated range.

A common use case for Ingress IP Self-Service is the ability to provide database services, such as PostgreSQL, to clients outside of the OpenShift Container Platform cluster, often using a Openshift Template

Configuration Details

  • EDGE ROUTER IP RANGE - The ability for cluster administrators to automatically allocate External IP addresses using the edge router is enabled by default within OpenShift Container Platform and configured to use the 172.46.0.0/16 range.

An alternate range can be specified by configuring the ingressIPNetworkCIDR parameter in the /etc/origin/master-config.yaml file:

networkConfig:
  ingressIPNetworkCIDR: 10.9.54.0/25

Configuring Routes

An OpenShift can expose a Service with a hostname like www.example.com, so that external clients can reach it by name

DNS resolution for a host name is handled separately from routing. The Openshift

  • administrator configures a DNS wildcard entry that will resolve to the OpenShift Node that is running the OpenShift Router.
  • If you are using a different host name you may need to modify its DNS records independently to resolve to the node that is running the router.

Each route consists of:

  • name (limited to 63 characters)
  • a service selector
  • an optional security configuration.

The Routing services is plug-able and other services may be added the The HAProxy template router is the default plug-in.

  • configuration for this router implementation is stored in the haproxy-config.template file located in the /var/lib/haproxy/conf
  • sticky sessions is up to the underlying router configuration.
  • configuration settings can be made on the deployment config for the router
  • to alter its configuration, or use the oc set env command e.g:
oc set env <object_type>/<object_name> KEY1=VALUE1 KEY2=VALUE2

or a more concrete example:

$ oc set env dc/router ROUTER_SYSLOG_ADDRESS=127.0.0.1 ROUTER_LOG_LEVEL=debug

A list of config parameters are on https://docs.openshift.com/container-platform/3.3/architecture/core_concepts/routes.html#env-variables

Named Route Host Names

Openshift allows you to associate a service with an externally-reachable host name.

This edge “host name” is then routed appropriately internally

An example route with a specified host name:

apiVersion: v1
kind: Route
metadata:
  name: host-route
spec:
  host: www.example.com  
  to:
    kind: Service
    name: service-name

If a host name is not provided as part of the route definition, then OpenShift automatically generates a generic one.

Adding some options. Routes can be:

  • unsecured - no config options provided
  • secured
apiVersion: v1
kind: Route
metadata:
  name: route-edge-secured 
spec:
  host: www.example.com
  to:
    kind: Service
    name: service-name // <== 1
  tls:
    termination: edge  // <= 2          
    key: |-            // <= 3          
      -----BEGIN PRIVATE KEY-----
      [...]
      -----END PRIVATE KEY-----
    certificate: |-              
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
    caCertificate: |-       // <= 5     
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
  1. The name of the object is limited to 63 characters.
  2. The termination field is edge for edge termination.
  3. The key field is the contents of the PEM format key file.
  4. The certificate field is the contents of the PEM format certificate file.
  5. An optional CA certificate may be required to establish a certificate chain for validation.

URL Path Routing

Handy to use the same hostname and route according to the path, most likely a micro service.

Routing based on a path:

apiVersion: v1
kind: Route
metadata:
  name: route-unsecured
spec:
  host: www.example.com
  path: "/test"   
  to:
    kind: Service
    name: service-name

Example: Exposing Kafka using Openshift Routes

To Expose Kafka using OpenShift Routes configure it in the Kafka custom resource.

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    listeners:
      # ...
      external:
        type: route
    # ...
 
openshift_routes.txt · Last modified: 2019/11/22 08:05 by root
 
RSS - 200 © CrosswireDigitialMedia Ltd