If you are not familiar with the oc command, refer to OpenShift - Getting Started with the oc command.

A route or an ingress object will provide a URL such as hello-world.apps.openshift.example.com which is used to route a request onto a service, which is then routed onto a pod, and then to the container in the pod, and finally to the application running in the container.

Like this.

The oc expose pod command can be used to create a ClusterIP service that will be used to route a request onto a pod. In this example, a ClusterIP service is created that will be used to route a request onto the hello-openshift pod.

~]$ oc expose pod hello-world-9mzm2
service/hello-world-9mzm2 exposed

These are commonly used option.

• --name = the name of the service
• --port = the port the service is listening for requests on (incoming port)
• --target-port = the port the service will forward requests to (must be a port the pod is listening on)

~]$ oc expose pod hello-world-9mzm2 --name my-service --port 12345 --target-port 8080
service/my-service exposed

The oc get services command should show the service has been created.

~]$ oc get services
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
my-service   ClusterIP   172.30.179.246   <none>        8080/TCP   3m24s

The oc describe service command can be used to display more details for the service.

When a pod is restarted, the pod will get a new private (internal) IP address. The service will automatically detect the pods new private IP address so that requests continue to be routed from the service to the pod.

~]$ oc describe service my-service
Name:              my-service
Namespace:         my-project
Labels:            <none>
Annotations:       <none>
Selector:          name=hello-world-9mzm2
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                172.30.179.246
IPs:               172.30.179.246
Port:              <unset>  8080/TCP
TargetPort:        8080/TCP
Endpoints:         10.217.0.68:8080
Session Affinity:  None
Events:            <none>

NSLOOKUP

A service establishes a static DNS name that is used to forward a request onto a pod and the service will always point to the private IP address and port being used by the pod.

The oc exec and nslookup command can be used to see that any pod in the same project / namespace as the service is now able to resolve the service name to the CLUSTER-IP address of the service. If the pod does not have the nslookup command install, you may need to update to deployment to run as root and then use the dnf install or yum install command to install the bind-utils package.

Notice that the fully qualified domain name (FQDN) is my-service.my-project.svc.cluster.local. The FQDN format is <service name>.<namespace>.svc.cluster.local.

~]$ oc exec pod/hello-world-9mzm2 -- nslookup my-service
Server:         172.30.0.10
Address:        172.30.0.10#53

Name:   my-service.my-project.svc.cluster.local
Address: 172.30.179.246

Now the oc exec and curl command can be used to submit a request from the hello-world-1 pod to the hello-world-2 service using the name of the service instead of the IP address of the pod.

~]# oc exec pod/hello-world-1-9mzm2 -- curl my-service:8080 -v
* About to connect() to my-service port 8080 (#0)
*   Trying 172.30.179.246...
* Connected to my-service (172.30.179.246) port 8080 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: my-service:8080
> Accept: */*
> 
< HTTP/1.1 200
< Content-Type: text/html;charset=utf-8
< Content-Language: en
< Content-Length: 431
< Date: Mon, 12 Sep 2022 07:06:48 GMT
<
Hello World

This works because when you expose the service, the service know that requests on port 8080 go to the pod with IP address 10.131.5.3 (in this example), which is the hello-world pod.

~]$ oc describe service my-service
Endpoints:         10.217.0.68:8080