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.
Related
I have an existing kind k8s cluster with a bunch of running services and nginx-ingress setup and I would like to add knative to it.
Is there a way of doing this with nginx-ingress, seems like networking for knative is a bit more complex than a normal service installation.
Knative needs more capabilities out of the HTTP routing layer than are exposed via the Kubernetes Ingress resource. (Percentage splits and header rewrite are two of the big ones.)
Unfortunately, so one has written an adapter from Knative's "KIngress" implementation to the nginx ingress. In the future, the gateway API (aka "Ingress V2") may provide these capabilities; in the meantime, you'll need to install one of the other network adapters and ingress implementations. Kourier provides the smallest implementation, while Contour also provides an Ingress implementation if you want to switch from nginx entirely.
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?
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.
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.