We have a camel application integrated with hawtio and deployed in openshift environment. This application has been scaled into two pod and exposed to the outside world through openshift route.
So through hawtio actuator url, when we changed the camel routes on runtime, it has been reflected on either of the pods and not in both. We are looking for a solution, where we can update the camel route on both the pods through hawtio url.
Anybody faced a similar sort of issue? please advice.
Hawtio online is the solution for OpenShift:
https://github.com/hawtio/hawtio-online
That said, generally it's not recommended to change Camel routes on the fly on each pod. You can instead redeply the changed deployment and then let it replicate the pods on OpenShift.
Related
I have an application running in Openshift 4.6.
The pod is running, I can exec into it and check this, I can port-forward to it and access it.
when trying to access the application, I get the error message:
Application is not available The application is currently not serving
requests at this endpoint. It may not have been started or is still
starting.
Possible reasons you are seeing this page:
The host doesn't exist. Make sure the hostname was typed correctly and
that a route matching this hostname exists.
The host exists, but doesn't have a matching path. Check if the URL
path was typed correctly and that the route was created using the
desired path.
Route and path matches, but all pods are down. Make sure that the
resources exposed by this route (pods, services, deployment configs,
etc) have at least one pod running.
There could be multiple reasons for this. You don't really provide enough debugging details to get to the next steps. But I generally find it helps to work backwards through the request.
Can you access the pod via port-forward? You say you've already tested this, but I include it for completeness. But I also mention it to make sure that you are verifying that you are serving the protocol you expect. If you have HTTPS passthrough on the route, but you are serving HTTP from your pod, there will obviously be a problem.
Can you access the pod providing your service from outside the pod (but within the cluster)? e.g. create a debug pod and see if you can connect to your service with curl some other client. If this doesn't work, you may not be exposing the ports of your pod correctly. Check the pod definitions.
Can you access the service from outside the pod (but within the cluster)? e.g. from your debug pod, use the service directly. If this doesn't work, you may have the selector on your service wrong. Or some other problem with your service. Check the service definition.
Can you access the route from inside the cluster? e.g. from your debug pod, try to use the full route URL. If this doesn't work, you've narrowed it down to the route definition. Again, HTTPS vs HTTP can sometimes be a mistake here such as having HTTPS passthrough when your service doesn't support HTTPS. Check the route definition.
Finally, try accessing the route eternally. Which is sounds like you have already tried. But if you've narrowed it down such that your route works internally you've determined that the problem is something in the external network. It doesn't sound like this is your problem, but it's something to keep in mind.
I have spring boot admin server deployed in openshift with the help of fabric8 maven plugin
And also i have several applications deployed in openshift.
Spring boot admin server (SBAS) use spring cloud kubernetes discovery to discover services (applications) registered / running in namespace / cluster, which is automatic client discovery.
SBAS discovered as expected, its fine but some applications shown / registered in SBAS use http and some use https to check the health as like below
I have no idea, why SBAS use http for some apps and for https for some apps to check the health.
Since SBAS use https and port 8443 it shows applications are offline but those applications are exposed in http 8080 only
I have compared applications code and openshift configurations but i don't see any difference and how to fix this issue.
I am new to all above concepts could some one help me ?
I didn't find solution for this issue, but i did work around which helped me.
Since i am using only one port 8080, i have deleted other ports such as 8443 and 8778 via openshif yml as shown below. but you have you have to expose more ports this won't help.
I have deployed an hawtio enabled spring-boot application in an openshift environment. But I am facing issue in accessing Jolokia endpoint through hawtio.
I noticed On the pod logs of my application, that set of actuator endpoints are exposed during startup where the Jolokia endpoint is not listed in that.
But I also could observe the below information in the startup logs
Jolokia: Agent started with URL https://ipaddress:8778/jolokia/
Bascially I suspect a conflict between the Jolokia endpoint that comes with spring-actuator and Openshift default Jolokia capabilities causing this issue.
Any Idea or Suggestion about the issue and fix?
This issue is resolved now
Solution: Disable the default Jolokia in openshift.
This issue has been resolved by disabling the default Jolokia through environment variable in openshift as per the documentation . Added the below Env variable:
AB_JOLOKIA_OFF: true
I need to deploy a few microservices on the Openshift. These microservices are implemented using Spring Cloud. I use Spring Eureka for service discovery/load-balancing && Spring Zuul for service routing.
From what I understand, Openshift already provides these features ( service discovery, load balancing, routing ) via Kubernetes.
With this being said, can I integrate Spring Eureka and Spring Zuul with the openshift platform?
Woudn't it be redundant to add Spring Eureka & Spring Zuul components into Openshift since the platform itself already provides these microservice features ?
I was thinking of removing the service registry & routing Spring components and just implement routing using Openshift. However, that would leave the project heavily dependent on this cloud platform.
What would your approach be? Use the features provided by the OpenShift (routing, load balancing) or use the ones provided by the Spring framework and try to integrate them with the cloud platform?
Thanks
It would indeed be redundant.
Eureka can be replaced by Kubernetes services. (they provide a load balancer and a domain name for a group of pods)
Zuul can be replaced by OpenShift Routes for exposing your services.
If you are using a platform, use the platform provided functionality. Kubernetes services will be used on any Kubernetes based platform. So I think that's the easy one to replace and keep your coupling to the platform low. The routing can be more difficult, if Zuul is only used for routing; replace it with the OpenShift router. If Zuul also has other responsibilities like security it might be better to stick with Zuul.
I agree with #Jeff and I want to add about using spring zuul as a gateway instead of openshift routes:
If you use spring zuul as a gateway, you provide the accessing from single point to your cluster. Otherwise, your client you must know the urls exposing by openshift routes. It gets increase the complexity of your code and hard to maintain. A major benefit of using an API Gateway is that it encapsulates the internal structure of the application.
The other is about security. If you use openshift routes to expose your internal microservices, actually you open door of the microservice to the public world directly. In addition, If you want to use JWT or security token, you should choose the spring zuul.
The API Gateway provides each kind of client with a specific API. This reduces the number of round trips between the client and application.
I have two openshift routers, running as pods, running in OSE.
However, I don't see any associated services in my openshift cluster which forwards traffic / loadbalances to them.
Should I expose my routers to the external world in a normal OSE environment?
Note that this is in a running openshift (OSE) cluster, so I do not think it would be appropriate to recreate the routers with new service accounts, and even if I did want to do this, it isn't always gauranteed that I will have access inside of OpenShift to do so.
If you are talking about the haproxy routers which are a part of the OpenShift platform, and which handle routing of external HTTP/HTTPS requests through to the pods of an application which has been exposed using a route, then no, you should not at least expose then as an OpenShift Route. Adding a Route for them would be circular as the router is what implements the route.
The incoming port of the haproxy routers does need to be exposed outside of the cluster, but this should have been handled as part of the setup you did when the OpenShift cluster was installed. Exactly what you may needed to have done to prepare for that when installing the OpenShift cluster depends on your target system into which OpenShift was installed.
It may be better to step back and explain the problem you are having. If it is an installation issue, you may be better asking on one of the lists at:
https://lists.openshift.redhat.com/openshiftmm/listinfo
as that is more frequented by people more familiar with installing OpenShift.