Perhaps you can help me out. I'm wondering where Istio (and other meshes) fit into the picture when deploying to k8s. The Itsio docs mention it is deployed as a side car, but is that within each pod? And are Service objects still required?
Here is my mental model of a traditional deployment (EKS):
Service[Type: LoadBalancer] -> Deployment[Pod]
How does Itsio fit into this scenario, or what does it replace?
Generally traffic is defined as north/south (into and out of the datacenter) or east/west (between servers in the datacenter).
Istio is for east/west traffic within your K8S cluster, designed to connect your services together by moving all the network traffic through the Envoy proxy. It is usually done by wrapping your deployments with an extra sidecar pod (automatically using K8S APIs) that intercepts all the networking to other services and pods. You would still use a load balancer or ingress to route external traffic into the cluster, although there are options like Heptio Contour that also use Envoy for this.
This provides a single data and control plane to centralize all network reliability, security, service discovery, and monitoring.
GP asked about Service objects though. k8s natively provides name resolution, traffic routing and load balancing to your defined service objects. So what does Envoy do for me that k8s does not do itself?
This brings about a major problem with centralized route management, though, in that you then must build all of your access controls around URLs rather than deeper business logic.
Istio offers much more, but as far as anything but coarse-grained "this service will never need to talk to this other service" access control, I'd still much rather write the logic in the code where it has access to a lot more domain knowledge.
Assuming your actors use queues, as they traditionally would, I don't think so. You don't really need service mesh if your communication is a queue, right?
I was wondering more about orchestration of the actors... something needs to be responsible for spawning them onto machines and something needs to be responsible for tracking where they are or where their queues are. I love MSFT Orleans but I'd love even more something that fit easier into a conventional node.js and docker kind of world (C# is great but when I look at adoption curves Typescript seems to be growing fast while C# seems to be at best holding steady)
I am looking forwards to digging in to this a bit more and figuring out how this compares to Istio. I am guessing integration with AWS services such as X-ray and Cloudwatch/logs are the selling point. Still, I am a bit weary about configuring things that run inside your Kubernetes cluster through amazon apis, and not k8s resources. However, you could easily create a custom resource for this. Maybe that is to come?
EKS is still young and they are yet to figure a lot of things out, from what i've seen, the roadmap is promising though. I have been working with it a lot, kops still wins for small/medium workloads in production, but I doubt for much longer.
shubha from AWS here, we built App Mesh to enable customers to use microservices in any compute service in AWS - be it ECS, Fargate, EKS or even directly on EC2. You configure capabilities using APIs and App Mesh configures Envoy proxies deployed with your pods.
The ports that are common are the envoy ports. In the roadmap it's mentioned that support for istio mixer is planned implying that mixer isn't supported now which, if it was istio, it would be.
We chose to use some common configuration for deploying Envoy to drive consistency there, but App Mesh itself is a custom control plane for managing Envoy.
Well, it’s Re:Invent this week (AWS’ major annual conference), so this is fairly typical. Expect another handful or so of announcements tomorrow during Werner Vogel’s keynote as well.
I wonder if this integrates with AWS Certificate Manager to provision HTTPS certificates so that traffic can be end-to-end encrypted.
That's one of the reasons I've stuck to Application Load Balancers in front of services instead of using ECS/Route53 service discovery.
35 comments
[ 2.8 ms ] story [ 91.7 ms ] threadHere is my mental model of a traditional deployment (EKS):
Service[Type: LoadBalancer] -> Deployment[Pod]
How does Itsio fit into this scenario, or what does it replace?
Istio is for east/west traffic within your K8S cluster, designed to connect your services together by moving all the network traffic through the Envoy proxy. It is usually done by wrapping your deployments with an extra sidecar pod (automatically using K8S APIs) that intercepts all the networking to other services and pods. You would still use a load balancer or ingress to route external traffic into the cluster, although there are options like Heptio Contour that also use Envoy for this.
This provides a single data and control plane to centralize all network reliability, security, service discovery, and monitoring.
Istio offers much more, but as far as anything but coarse-grained "this service will never need to talk to this other service" access control, I'd still much rather write the logic in the code where it has access to a lot more domain knowledge.
Personally, I think that Istio is overly complex but then so is k8s :)
[1] https://kubernetes.io/docs/concepts/services-networking/netw...
Smaller clusters or services don't need it. The docs overview page is worth a read: https://istio.io/docs/concepts/what-is-istio/
We chose to use some common configuration for deploying Envoy to drive consistency there, but App Mesh itself is a custom control plane for managing Envoy.
https://blog.envoyproxy.io/envoy-graduates-a6f71879852e