Skip to main content
Welcome to this OpenShift demo. This lesson shows how to expose your application inside the cluster using a Service, and how to make it reachable from the outside using an OpenShift Route. We assume you already have builds and deployments configured for your app. The next step is to create a Service so other applications (or internal cluster components) can reach your pods, and then create a Route to expose the Service externally.

​
1) Create a Service YAML template

Get a Service template from the OpenShift web console (use the “Learn More” link or the Import YAML/JSON option), then:
  1. Create a file named service-config.yaml.
  2. Paste the template contents into it.
  3. Update:
    • metadata.name to a meaningful name for your app.
    • spec.selector to match the labels used by your Deployment/DeploymentConfig. This selector decides which pods receive traffic from the Service.
Important: you usually do not need to set clusterIP in the YAML — OpenShift assigns it automatically unless you have a specific requirement.

​
Service field quick reference

Here is a minimal Service definition for an app listening on port 8080:
Create the Service:
  • In the OpenShift web console, use Import YAML/JSON, paste the YAML above, and click Create.
  • After creation, OpenShift assigns a Cluster IP that is internal to the cluster.
A screenshot of the OpenShift Origin web console on the "Services" page for a project called "My WebApplication," listing two services ("simple-webapp-docker" and "simple-webapp") with Cluster IPs and ports (8080/TCP).
Cluster IPs are internal to the cluster. To make your application accessible externally, you must create a Route (or use a LoadBalancer/NodePort depending on your environment).

​
2) Test the Service from inside the cluster/network

If you have access to the OpenShift host or the Minishift/OKD VM, you can curl the Service’s cluster IP and port to verify the application responds: Example (from the Minishift VM shell):
This confirms the Service is forwarding traffic to the pod/container correctly.

​
3) Create a Route (external access)

To expose the Service to external users, create an OpenShift Route which maps a hostname to the Service. Options:
  • Create a Route via YAML (similar to the Service), or
  • Use the web console: Applications → Routes → Create Route (or use the Create Route form accessed from the Service details).
In the Create Route form:
  • Name: give the route a descriptive name.
  • Hostname: leave blank to let OpenShift generate one (recommended for quick testing). Or set a custom hostname if you control DNS.
  • Service: choose the Service (e.g., simple-webapp-docker).
  • Target Port: select the Service port (e.g., 8080).
If you plan to use a custom hostname, ensure external DNS points the hostname to the OpenShift router (the cluster ingress). Only after DNS directs traffic to the router will the route reach your application.
Using a custom hostname requires external DNS to point to your cluster’s router IP or load balancer. Without proper DNS, the hostname will not resolve to the OpenShift router and traffic won’t reach your app.
A screenshot of the OpenShift Origin web console open to the "Create Route" page for a project called "My WebApplication," showing fields for Name, Hostname, Path, Service, and Target Port. The left sidebar displays navigation items like Applications, Builds, Resources, Storage, and Monitoring.
After creating the Route, you can view the generated hostname in the Routes list or in the Service details. Click the URL to open the application in your browser.
A screenshot of the OpenShift Origin web console displaying the "simple-webapp-docker" service details, including selectors, IP/hostname, route and traffic information. The page also shows a pod entry with status "Running" and the service port mapped to 8080.

​
4) End-to-end flow after a code change (CI/CD)

When you update your application source (for example, changing the displayed text from “Update 4” to “Update 5”):
  1. Your CI/CD pipeline or OpenShift build picks up the changes and produces a new image.
  2. OpenShift deploys the new image, creating updated pods.
  3. The existing Service and Route continue to route traffic to the new pods.
  4. Refreshing the browser at the Route URL will display the updated application.
That’s it — you’ve exposed your app internally with a Service and externally with a Route.

Watch Video