I know envoy is the default service mesh for Istio, we implemented our own service mesh and hope to integrate with Istio. so we can leverage Istio to integrate with a lot of components like eureka, cf, statsd, prometheus
My quesion is where I can find the pilot, mixer,and auth API. if possieble plz tell me briefly how to interact with them in runtime.
All Istio APIs are located in https://github.com/istio/api
Related
I have an application running in EKS with istio service mesh, exposed using istio ingress and alb. Is there a tool to measure the amount of time (response time) taken by API request on each service? For instance, what time it reached ingress, then gateway and virtual service down to the pod?
Istio access logs can be enabled to see different details. Below is default logging format.
[%START_TIME%] \"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%\" %RESPONSE_CODE% %RESPONSE_FLAGS% %RESPONSE_CODE_DETAILS% %CONNECTION_TERMINATION_DETAILS%
\"%UPSTREAM_TRANSPORT_FAILURE_REASON%\" %BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% \"%REQ(X-FORWARDED-FOR)%\" \"%REQ(USER-AGENT)%\" \"%REQ(X-REQUEST-ID)%\"
\"%REQ(:AUTHORITY)%\" \"%UPSTREAM_HOST%\" %UPSTREAM_CLUSTER% %UPSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_REMOTE_ADDRESS% %REQUESTED_SERVER_NAME% %ROUTE_NAME%\n
For istio observability to visualize service mesh please refer their documentation.
I would like to enable mTLS between services in one K8S namespace. I wonder if I can do it without using service mesh? I considered cert-manager but all the examples I've seen involved Ingress resource which I do not need as my services are not exposed outside of the cluster.Thanks
Using Service Mesh like Istio or Linkerd for this is currently the only general solution for this.
It should be possible to do this using a library for you app as well, the library typically would need to support certificate management. Service Meshes typically use EnvoyProxy as a sidecar, it has implemented novel "control plane" APIs for management, called xDS protocols - this is something that your library typically would need to implement. In addition you need a control plane interface to manage services.
A drawback with doing this in a library is that it will be language-dependent. But the pro is that it will be better performant.
Google has recently taking this route with Traffic Director - proxyless service mesh
You need something like SPIRE together with SPIRE integration operator. Together, they can create mTLS keys and certificates for use within a cluster, where the only configuration you need is pod annotations. The mTLS keypairs are provided as secrets, which you mount into your pods. SPIRE & the operator automatically handle keypair and CA rotation and update the Secrets accordingly.
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.
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.
Currently, I want to introduce istio as our service-mesh framework for our microservices. I have played it sometime (< 1 week), and my understanding is that Istio really provides an easy way to secure service to service communication. Much (or all?) of Istio docs/article provides an example how client and server who have istio-proxy (envoy) installed as a sidecar container, can establish secure communication using mtls method.
However, since our existing client (which I don't have any control) who consume our service (which will be migrated to use istio) doesn't have istio, I still don't understand it well how we should do it better.
Is there any tutorial or example that provides my use case better?
How can the non-istio-based client use mtls for consuming our istio-based service? Think about using basic curl command to simulate such thing.
Also, I am thinking of distributing a specific service account (kubernetes, gcp iam service account, etc) to the client to limit the client's privilege when calling our service. I have many questions on how these things: gcp iam service account, istio, rbac, mtls, jwt token, etc contributes to securing our service API?
Any advice?
You want to add a third party to your Istio mesh outside of your network via SSL over public internet?
I dont think Istio is really meant for federating external services but you could just have an istio ingress gateway proxy sat at the edge of your network for routing into and back out of your application.
https://istio.io/docs/tasks/traffic-management/ingress/
If you're building microservices then surely you have an endpoint or gateway, that seems more sensible to me, try Apigee or something.