Managing Virtual Machines with Red Hat OpenShift Virtualization

Service resources use the ClusterIP resource type by default. With that type, the service is accessible only from inside the cluster.

By setting the type parameter to NodePort, Kubernetes opens the same network port on all the cluster nodes and then redirects the incoming traffic to your pods or VMs. By default, Kubernetes allocates a port in the 30000 to 32767 range.

With this configuration, an external client can reach your service by targeting the IP address of one of your cluster nodes and the allocated port.

Figure 3.22: Incoming traffic through a node port service

The following service definition declares a service resource of the NodePort type:

apiVersion: v1
kind: Service
metadata:
  name: database
  namespace: prod2
spec:
  type: NodePort  
  selector:
    vmtype: linux
  ports:
    - protocol: TCP
      port: 3306  
      targetPort: 3306
      nodePort: 30336  

Although it is possible to use the NodePort service type for TCP and UDP traffic, Red Hat recommends avoiding the use of the NodePort service type, for the following reasons:

You can create services of the LoadBalancer type to provide external access to your applications on clusters that are deployed on cloud infrastructure. When you create that type of service, Kubernetes automatically configures an external load balancer from the cloud provider. For example, when you create a service on a cluster that is deployed on Amazon Web Services (AWS), Kubernetes creates a load balancer with Amazon Elastic Load Balancing (ELB). With a cluster that is deployed on IBM Cloud, Kubernetes creates the load balancers with IBM Cloud load balancers, and on Microsoft Azure, Kubernetes creates the load balancers with Azure Load Balancer.

Figure 3.23: Incoming traffic through the cloud provider load balancer

The following service definition declares a service resource of the LoadBalancer type, which defines a loadBalancerIP IP address:

apiVersion: v1
kind: Service
metadata:
  name: frontend
  namespace: prod2
spec:
  type: LoadBalancer  
  loadBalancerIP: 40.121.123.12  
  selector:
    tier: frontend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

For clusters that are deployed on bare metal, services of the LoadBalancer type behave differently. Kubernetes assigns an IP address to the service from a pool of external addresses that the cluster administrators prepare.

Cluster administrators must configure these external IP addresses so that the network can route them to a cluster node. When the cluster nodes receive packets where the destination IP is the external IP of the service, they forward the traffic to the pods or virtual machines that are associated with the service.

The following service definition declares a service resource of type LoadBalancer that defines an externalIP IP address:

apiVersion: v1
kind: Service
metadata:
  name: frontend
  namespace: prod2
spec:
  type: LoadBalancer 
  externalIPs:
    - 192.168.0.42 
  selector:
    tier: frontend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

MetalLB is a load balancer component that provides a load balancing service for clusters that do not run on a cloud provider, such as a bare metal cluster, or clusters that run on hypervisors. MetalLB operates in two modes: layer 2 and Border Gateway Protocol (BGP), with different properties and requirements. You must plan the use of MetalLB to consider your requirements and your network design.

MetalLB is an operator that you can install with the Operator Lifecycle Manager. After installing the operator, you must configure MetalLB through its custom resource definitions. In most situations, you must provide MetalLB with an IP address range.

After creating a service of the ClusterIP type, which points to your pods or virtual machines, you can create a route for your application. You can create a resource file in the YAML or the JSON format to declare your route. However, Red Hat OpenShift provides the oc expose service command to simplify the creation process:

[user@host ~]$ oc expose service/web
route.route.openshift.io/web exposed

That command creates a route resource with the same name as the service. Use the --name option to define a different name.

Red Hat OpenShift automatically assigns a DNS name to the route. You can use the --hostname option followed by the DNS name to define it manually. The following command creates a db-connection route that defines the db-connection-production.apps.mycompany.com hostname.

[user@host ~]$ oc expose service/web --name web --hostname web-production.apps.mycompany.com
route.route.openshift.io/web exposed

Use the oc get route command to retrieve the DNS name that is assigned to the route:

[user@host ~]$ oc get route web
NAME  HOST/PORT                         PATH  SERVICES  PORT TERMINATION  WILDCARD
web   web-production.apps.mycompany.com       web       8080              None

From the web console, navigate to Networking → Routes, select a namespace, click Create Route, and then complete the form with the route details. You must name the route and select the associated service and its ports.

Figure 3.25: Create a route by using the web console

The route resource definition accepts the path variable to specify the path component to the URL. With that configuration, you can use the same DNS name for several services and redirect the traffic based on the path component. For example, you could use the http://intranet-prod.apps.mycompany.com/static URL to send traffic to pods or to virtual machines that serve static web content. For REST API requests, you could use the http://intranet-prod.apps.mycompany.com/api URL to forward the traffic to the application back end.

Add the --path option to the oc expose service command to configure path-based routes:

[user@host ~]$ oc expose service/static --path=/static \
  --hostname=intranet-prod.apps.mycompany.com
route.route.openshift.io/static exposed
[user@host ~]$ oc expose service/restapi --path=/api \
  --hostname=intranet-prod.apps.mycompany.com
route.route.openshift.io/restapi exposed
[user@host ~]$ oc get routes
NAME     HOST/PORT                          PATH      SERVICES   PORT ...
static   intranet-prod.apps.mycompany.com   /static   static     8080 ...
restapi  intranet-prod.apps.mycompany.com   /api      restapi    80   ...

Routes can be secured (TLS or HTTPS) or unsecured (HTTP). Secure routes enable using several types of TLS termination to serve certificates to the client.

A secured route specifies the TLS termination of the route. The following list describes the available termination types:

The references section at the end provides links to documents that explain how to configure secured routes.

To configure a route for a VM, you must first create a service for the virt-launcher pod of the VM:

apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: prod2
spec:
  type: ClusterIP
  selector:
    tier: front
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

After you create the service, you can then create the route.

From the command line, use the oc expose service command to create the route:

[user@host ~]$ oc expose service/web
route.route.openshift.io/web exposed

When you use network policies in your project, you must add a rule to enable the traffic that comes from the router pods. Otherwise, the route resources do not work, because the router pods cannot reach the destinations pods and virtual machines.

The router pods run in the openshift-ingress namespace. That namespace already has a label that you can use with your network policies. The following command shows that the label is network.openshift.io/policy-group: ingress:

[user@host ~]$ oc get namespace openshift-ingress -o yaml
kind: Namespace
apiVersion: v1
metadata:
...output omitted...
  labels:
    kubernetes.io/metadata.name: openshift-ingress
    name: openshift-ingress
    network.openshift.io/policy-group: ingress
    olm.operatorgroup.uid/44814614-edc3-4e46-9491-5f0f97af9c84: ""
    openshift.io/cluster-monitoring: "true"
    policy-group.network.openshift.io/ingress: ""
...output omitted...

Add the following NetworkPolicy resource to your project to enable the traffic from the router pods:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-from-openshift-ingress
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          network.openshift.io/policy-group: ingress  
  podSelector: {}