在OpenShift上部署并暴露微服务：路径路由方案咨询

Hey there! Let's break this down clearly since you're new to Kubernetes and OpenShift—no overly technical jargon, I promise. First, I'll demystify those confusing terms, then walk you through the best way to set up that unified access for your microservices on OpenShift 4.2.18.

Key Terms Explained #

Let's start with the basics so you know exactly what each tool does:

• OpenShift Route: This is OpenShift's native resource for exposing services to the outside world. Think of it as a beefed-up version of Kubernetes Ingress, tightly integrated with OpenShift's built-in router (which uses HAProxy under the hood). It handles TLS, path-based routing, and works seamlessly with OpenShift's ecosystem.
• Kubernetes Ingress: The standard Kubernetes resource for defining external access rules to cluster services. But it needs an Ingress Controller (like HAProxy or NGINX) to actually route traffic. OpenShift Routes are built on top of Ingress but are more tailored to OpenShift's workflows.
• VirtualService: A core resource in the Istio service mesh. It lets you define advanced traffic rules—like routing to specific service versions, splitting traffic, or adding fault injection. It's powerful, but only useful if you're running Istio.
• HA-Proxy: An open-source load balancer and reverse proxy. OpenShift's default router is built using HAProxy—it's the workhorse that actually forwards external traffic to your services, whether you use Routes or Ingress.
• Istio: A full-featured service mesh framework that adds traffic management, observability, and security to your microservices. It's great for complex architectures, but has a steeper learning curve and requires extra setup.

Best Solution for Your OpenShift 4.2.18 Setup #

Since you already have your Services and Deployments ready, OpenShift Routes are the simplest, most native way to get that unified IP/domain with virtual paths. Here's how to set it up:

1. Get your cluster's unified entry point #

First, find the external host/IP of OpenShift's default router (this will be your single access point):

oc get route -n openshift-ingress

Look for the HOST/PORT value in the output—something like router-default.apps.your-cluster.com. This is the base address all your microservice paths will attach to.

2. Create a Route for each microservice #

For each microservice, create a Route that maps a specific path to its Service. Here's an example YAML for microservice1:

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: microservice1-route
spec:
  host: router-default.apps.your-cluster.com  # Use the host from step 1
  path: /microservice1
  to:
    kind: Service
    name: microservice1-service  # Your existing Service name
  port:
    targetPort: 8080  # The port your Service exposes
  tls:
    termination: edge  # Enables HTTPS; OpenShift manages certificates automatically

Repeat this for microservice2 (and others), changing the path to /microservice2 and pointing to its corresponding Service.

3. Test your access #

Once the Routes are created, you can access your microservices via:

• https://router-default.apps.your-cluster.com/microservice1/
• https://router-default.apps.your-cluster.com/microservice2/

All traffic goes through the same unified entry point—exactly what you wanted!

When to Consider Other Tools? #

• Istio + VirtualService: Only use this if you need advanced traffic control later (like rolling out new versions gradually, splitting traffic between services, or adding circuit breakers). It's overkill for basic path routing, but invaluable for complex microservice architectures.
• Kubernetes Ingress: You can use this in OpenShift, but Routes are more integrated and require less setup (since OpenShift's router already acts as the Ingress Controller). Stick with Routes unless you have a specific reason to use vanilla Ingress.

内容的提问来源于stack exchange，提问作者happy-integer