I am looking for a straightforward way to setup GKE for a new project so that I can use less demanding nodes in a Google managed environment.
I have setup GKE in a previous example with Istio and its Ingress gateway. This works perfectly fine although I feel that I am overcomplicating things and I need to use N1 machines which are quite costly to start the project with. See documentation below.
https://istio.io/latest/docs/setup/platform-setup/gke/
Now I was looking into the GKE Gateway controller. The thought process on how to use it, seemed quite nice, although, I am missing a bunch of stuff.
Now my question is, imagine that I want to use GKE Gateway controller instead of an Istio Ingress gateway. Can I manage the centralized auth flow like Istio offers with its RequestAuthentication and AuthorizationPolicy kinds
(https://istio.io/latest/docs/tasks/security/authorization/authz-jwt/)
In the GKE Gateway controller?
Related
Im trying to set up a simple k8s cluster on a bare metal server.
Im looking into ways to access the cluster.
Ive been looking though the docs and read through the bare metal considerations section.
so far i've found setting external IP's and nodePorts aren't recommended.
Ive heard metalLB should be used in production so i was about to go ahead with that.
Then i realised the ingress is already using a nodePort service and i can access that for development purposes.
Could i just use this in production too?
Of course you can. If you do not need routing rules or anything beyond what kube-proxy can offer, you don't need ingress controller like MetalLB.
I have been using Ambassador for a while, I like it but it's been spamming my logs with GET /api/.ambassador-internal/openapi-docs. So I'm thinking to switch to another mapping alternative and I found Istio. I'm not sure what exactly what is yet, but seems like I can use it to replace ambassador mapping.
So my question is that if I use Istio do I even need Ambassador?
Ambassador is essentially a Kubernetes ingress controller/API gateway that uses Envoy.
And Istio is a service mesh that happens to have its own ingress mechanism, and Istio also uses Envoy as sidecar proxies. So in a way yes, you can replace Ambassador with Istio, but you may not be able to get the API gateway type of features with Istio. This blog explains the differences and attempts to clarify the confusion.
I'm not really sure that Istio is going to help you with the logs since it looks like the issue that you are seeing with log spamming is related to the API gateway component. It really depends on how you architect your application/services.
Currently, we have k8s cluster in our data center due to compliance reasons. We are running the traefik as an ingress controller. Now we want to have the service mesh added to it for monitoring the service level communication. Can you suggest me how can I do it? Do I replace the traefik ingress controller and have the istio ingress on the host network setup or any other better options without removing the traefik and have istio to it too?
If you are going to install Istio to get "free" observability features, you need to keep in mind that in some scenarios it directly doesn't fit. e.g. you want to get the latency within a service. not possible with Istio.
I would recommend you to get Istio, if you need service mesh and/or routing, besides observability, but don't install it just for observability. There are other tools out there specific for that.
Without counting the fact that you are going to use cluster resources, to get an extra container for each service, just for monitoring. Not a good approach, in my opinion.
I'm new in k8s world and using Openshift 4.2.18. I want to deploy a microservice on it. What I need is one common ip and being able to access each microservice using virtual path.
Like this,
https://my-common-ip/microservice1/
https://my-common-ip/microservice2/
https://my-common-ip/microservice3/
Service and deployment are OK. However I'm so confused with the other terms. Should I use route or ingress? Should I use VirtualService like in this link? Also heard about HA-Proxy and Istio. What's the best way of doing this? I would appreciate it if you could provide the information about these terms.
Thanks in advance, Best Regards
Route and ingress are intended to achieve the same end. Originally Kubernetes had no such concept and so in OpenShift the concept of a Route was developed, along with the bits for providing a load balancing proxy etc. In time it was seen as being useful to have something like this in Kubernetes, so using Route from OpenShift as a starting point for what could be done, Ingress was developed for Kubernetes. In the Ingress version they went for a more generic rules based system so how you specify them looks different, but the intent is to effectively be able to do the same thing.If you intend to deploy your application on multiple Kubernetes distributions at the same time then Ingress might be a good option.
Virtual service and istio is service mesh which is not necessary for external access of an app. You bring complexity with a service mesh. Unless the capabilities offered by a service mesh is really needed for your usecase there is no reason to use it.
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.