Is is right to set up the architect by using Keepalived and SpringCloud Zuul (work as gateway)?
Previously our architect is Keepalived + Nginx + Tomcat as shown below.
For now, we plan to use SpringCloud, nginx will be replaced by SpringCloud Zuul since Zuul (Ribbon) has similar functions as Nginx and we don't have very high concurrent requests. The new architect shows below
The questions are:
Is this design OK or any better designs?
Keepalived has to use IP points to SpringZuul, is it possible to use serivce name? If yes, what addtional softwares should be used?
Related
I would like to know what is/are differences between an api gateway and Ingress controller. People tend to use these terms interchangeably due to similar functionality they offer. When I say, 'Ingress controller'; don't confuse it with Ingress objects provided by kubernetes. Also, it would be nice if you can explain the scenario where one will be more useful than other.
Is api gateway a generic term used for traffic routers in cloud-native world and 'Ingress controller' is implementation of api-gateway in kubernetes world?
Ingress controller allows single ip-port to access all services running in k8s through ingress rules. The ingress controller service is set to load balancer so it is accessible from public internet.
An api gateway is used for application routing, rate limiting, security, request and response handling and other application related tasks. Say, you have a microservice based application in which the request needs an information to be collected from multiple micro services. You need a way to distribute the user requests to different services and gather the responses from all micro services and prepare the final response to be sent to the user. API Gateway is the one which does this kind of work for you.
Ingress
Ingress manages and route the traffic into Kubernetes services.
Ingress rules/config yaml and backed by Ingress controller (Nginx ingress controller famous one)
Ingress controller makes one Kubernetes service using that get exposed as LoadBalancer.
Other list of ingrss controller : https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/
For simple understanding, you can consider ingress as Nginx server which just do the work of forwarding the traffic to services based on the ruleset.
ingress don't have much functionality like API gateway. Some of ingress don't support authentication, rate limiting, application routing, security, merging response & request, and other add-ons/plugin options.
API gateway
API gateway can also do the work of simple routing but it's mostly gets used when you need higher flexibility, security and configuration options.
There are lots of parameters to compare when you are choosing the Ingress or API gateway however it's more depends on your usecase.
API gateway like KrakenD, Kong are way better compare to ingress have security integration like Oauth plugin, API key option, it support rate-limiting, API aggregation.
Kong API gateway also has a good plugin option which you can use if you want to configure logging/monitoring of traffic also.
There are so many API gateways available in the market same as the ingress controller, you can check the API gateway feature and comparison below.
Read more at : https://medium.com/#harsh.manvar111/api-gateway-identity-server-comparison-ec439468cc8a
If your use case is small and sure about requirement you can use the ingress also for production API gateway is not necessary.
Indeed both have a set of features that intersect, path mapping, path conversion, load balancing, etc.
However, they do differ. I may be wrong, but you create an Ingress 1) to run it in Kubernetes 2) to be more of like a reverse proxy "kubernetes native".
API Gateway could be installed anywhere (although there are now many that run in Kubernetes natively like Ambassador, Gloo, Kong), and they do have more functionality available like developer portal, rate limiting, etc.
Personally I use an ingress as a reverse proxy for a website. And API Gateway for APIs. This does not mean you can't use ingress for apis. However, you are not taking full advantage of them.
I have a cluster on AWS installed via kops. Now I need to expose a WebSocket service (with security enabled, the wss://) to the outside world. There are different ingress controllers, nginx, traefik, ELBs, ALBs. Which one is the suggested and:
easy to deploy and config
support http://, https://, ws://, and wss://
In my opinion this question is opinion based and too broad. Please try to avoid such questions as there is not one solution that is the best.
I was able to find plenty resources about nginx and websockets. I do not have production experience with configuring this, but I think you might find this helpful.
NGINX is a popular choice for an Ingress Controller for a variety of
features:
Websocket, which allows you to load balance Websocket applications.
SSL Services, which allows you to load balance HTTPS applications.
Rewrites, which allows you to rewrite the URI of a request before sending it to the application.
Session Persistence (NGINX Plus only), which guarantees that all the requests from the same client are always passed to the same
backend container.
Support for JWTs (NGINX Plus only), which allows NGINX Plus to authenticate requests by validating JSON Web Tokens (JWTs).
The most important part with nginx is the annotation - which specifies which services are Websocket services. Some more information about usage and configuration. Also useful tutorial about configuration of nginx ingress, although it is about GKE it might be useful.
I know that Consul is a tool for Service Discovery in the era of micro-services. But before Consul, HA Proxy was invented. So why do we need Consul for service discovery, or Consul is more powerful than HA Proxy? Is there any comparisons between Consul and HA Proxy? Please give me some advice, which should I use or can I use both of them.
HA Proxy is basically a high performance TCP/HTTP laod balancer and Consul provides both a DNS and HTTP interface for doing service discovery(Consul also provides other features as Key/Value store etc.)
Here is an article as to how you can use both HA proxy and consul together:
Another article here refers to dynamic load balancing using both these tools.
If you are using docker, you might want to look at this basic setup article.
PS : I haven't tried using Consul together with HA Proxy though I am working on two separate POC to use them in separate situations. I hope these articles will help you.
You can use Consul to find out that on which IPs and ports your service is running and then based on this info generate HAProxy config. Clients communication to backends would go via the HAProxy load balancer and they don't need to know about internal ips, ports or even Consul. Related to this question regarding service discovery.
In my current project we deploy our applications in an application server and provide load balancing via an Apache httpd server deployed in the DMZ. I'm in the early stage of considering the move to Spring Cloud and while studying it, I came across Zuul as an API Gateway providing reverse proxing, routing and load balancing. Here are my questions:
1) Is Zuul a replacement for an httpd server for the functions described above? (there are probably other functions that the httpd server might supply that Zuul can't, but I'd like to keep the answers limited to reverse proxy, routing and load balancing if possible)
2) Is it redundant to have Zuul front-ended by an httpd server? Or are there benefits of doing this?
Thank you in advance for your answers.
From this youtube Brendan Burns talks about having a load balancer between each app layer. This makes good sense - and when he says load balancer, he is talking about a services right?
The real question is, having a service between each layer makes sense, but what about when you have a web application. Would you still need a reverse proxy like nginx as HTTP load balancer on top of the Kubernetes services. I can see the need to direct the the url to prevent a cross domain, but not for balancing since this would be handled by the Kubernetes service, right?
Then would you have pods of nginx redirecting to other services(internal cabernets load balancer/services)?
Just saw this. Again any comments are welcome.
Thanks
Yes, there are definitely use cases for which you might want a reverse proxy in front of the Kubernetes services. Experimental support is being added for this to Kubernetes version 1.1.
You can check out the design proposal here and an implementation using haproxy here.