Most real-world applications do not run as a single pod. Because applications need to scale horizontally, many pods run the same containers from the same pod resource definition, to meet growing user demand. A service defines a single IP/port combination, and provides a single IP address to a pool of pods, and a load-balancing client request among member pods.

By default, services connect clients to pods in a round-robin fashion, and each service is assigned a unique IP address for clients to connect to. This IP address comes from an internal OpenShift virtual network, which although distinct from the pods' internal network, is visible only to pods. Each pod that matches the selector is added to the service resource as an endpoint.

Containers inside Kubernetes pods must not connect to each other's dynamic IP address directly. Services resolve this problem by linking more stable IP addresses from the SDN to the pods. If pods are restarted, replicated, or rescheduled to different nodes, then services are updated, to provide scalability and fault tolerance.

You can choose between several service types depending on your application needs, cluster infrastructure, and security requirements.

RHOCP provides resources to expose your applications to external networks outside the cluster. You can expose HTTP and HTTPS traffic, TCP applications, and also non-TCP traffic. However, you should expose only HTTP and TLS-based applications to external access. Applications that use other protocols, such as databases, are usually not exposed to external access (from outside a cluster). Routes and ingress are the main resources for handling ingress traffic.

RHOCP provides the route resource to expose your applications to external networks. With routes, you can access your application with a unique hostname that is publicly accessible. Routes rely on a Kubernetes ingress controller to redirect the traffic from the public IP address to pods. By default, Kubernetes provides an ingress controller, starting from the 1.24 release. For RHOCP clusters, the OpenShift ingress operator provides the ingress controller. RHOCP clusters can also use various third-party ingress controllers that can be deployed in parallel with the OpenShift ingress controller.

Routes provide ingress traffic to services in the cluster. Routes were created before Kubernetes ingress objects, and provide more features. Routes provide advanced features that Kubernetes ingress controllers might not support through a standard interface, such as TLS re-encryption, TLS passthrough, and split traffic for blue-green deployments.

To create a route with the oc CLI, use the oc expose service service-name command. Include the --hostname option to provide a custom hostname for the route.

[user@host ~]$ oc expose service api-frontend \
--hostname api.apps.acme.com

If you omit the hostname, then RHOCP automatically generates a hostname with the following structure: <route-name>-<project-name>.<default-domain>. For example, if you create a frontend route in an api project, in a cluster that uses apps.example.com as the wildcard domain, then the route hostname is as follows:

frontend-api.apps.example.com

Consider the following settings when creating a route:

The following listing shows a minimal definition for a route:

kind: Route
apiVersion: route.openshift.io/v1
metadata:
  name: a-simple-route 
  labels: 
    app: API
    name: api-frontend
spec:
  host: api.apps.acme.com 
  to:
    kind: Service
    name: api-frontend 
  port: 8080 
    targetPort: 8443

You can delete a route by using the oc delete route route-name command.

[user@host ~]$ oc delete route myapp-route

You can also expose a service from the web console by clicking the Networking → Routes menu. Click Create Route and customize the name, the hostname, the path, and the service to route to by using the form view or the YAML manifest.

An ingress is a Kubernetes resource that provides some of the same features as routes (which are an RHOCP resource). Ingress objects accept external requests and transfer the requests based on the route. You can enable only certain types of traffic: HTTP, HTTPS and server name identification (SNI), and TLS with SNI. Standard Kubernetes ingress resources are typically minimal. Many common features that applications rely on, such as TLS termination, path redirecting, and sticky sessions, depend on the ingress controller. Kubernetes does not define the configuration syntax. In RHOCP, routes are generated to meet the conditions that the ingress object specifies.

To create an ingress object, use the oc create ingress ingress-name --rule=URL_route=service-name:port-number command. Use the --rule option to provide a custom rule in the host/path=service:port[,tls=secretname] format. If the TLS option is omitted, then an insecure route is created.

[user@host ~]$ oc create ingress ingr-sakila \
--rule="ingr-sakila.apps.ocp4.example.com/*=sakila-service:8080"

The following listing shows a minimal definition for an ingress object:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: frontend 
spec:
  rules: 
  - host: "www.example.com 
    http:
      paths:
      - backend: 
          service:
            name: frontend
            port:
              number: 80
        pathType: Prefix
        path: /
  tls: 
  - hosts:
    - www.example.com
    secretName: example-com-tls-certificate

You can delete an ingress object by using the oc delete ingress ingress-name command.

[user@host ~]$ oc delete ingress example-ingress

Sticky sessions enable stateful application traffic by ensuring that all requests reach the same endpoint. RHOCP uses cookies to configure session persistence for ingress and route resources. The ingress controller selects an endpoint to handle any user requests, and creates a cookie for the session. The cookie is passed back in response to the request, and the user sends back the cookie with the next request in the session. The cookie tells the ingress controller which endpoint is handling the session, to ensure that client requests use the cookie so that they are routed to the same pod.

RHOCP auto-generates the cookie name for ingress and route resources. You can overwrite the default cookie name by using the annotate command with either the kubectl or the oc commands. With this annotation, the application that receives route traffic knows the cookie name.

The following example configures a cookie for an ingress object:

[user@host ~]$ oc annotate ingress ingr-example \
ingress.kubernetes.io/affinity=cookie

The following example configures a cookie named myapp for a route object:

[user@host ~]$ oc annotate route route-example \
router.openshift.io/cookie_name=myapp

After you annotate the route, capture the route hostname in a variable:

[user@host ~]$ ROUTE_NAME=$(oc get route <route_name> \
-o jsonpath='{.spec.host}')

Then, use the curl command to save the cookie and access the route:

[user@host ~]$ curl $ROUTE_NAME -k -c /tmp/cookie_jar

The cookie is passed back in response to the request, and is saved to the /tmp/cookie_jar directory. Use the curl command and the cookie that was saved from the previous command to connect to the route:

[user@host ~]$ curl $ROUTE_NAME -k -b /tmp/cookie_jar

By using the saved cookie, the request is sent to the same pod as the previous request.

Developers and administrators can choose to manually scale the number of replica pods in a deployment. More pods might be needed for an anticipated surge in traffic, or the pod count might be reduced to reclaim resources that the cluster can use elsewhere.

You can change the number of replicas in a deployment resource manually by using the oc scale command.

[user@host ~]$ oc scale --replicas 5 deployment/scale

The deployment resource propagates the change to the replica set. The replica set reacts to the change by creating pods (replicas) or by deleting existing ones, depending on whether the new intended replica count is less than or greater than the existing count.

Although you can manipulate a replica set resource directly, the recommended practice is to manipulate the deployment resource instead. A new deployment creates either a replica set or a replication controller, and direct changes to a previous replica set or replication controller are ignored.