5 ms·

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

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?

manigandham 8y ago
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.
- jeremyjh 8y ago
  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?
  - gauravphoenix 8y ago
    things like layer 7 control, you can say - "don't allow HTTP GET on /supersecret". Also, Isito is gRPC aware
    - andrewstuart2 8y ago
      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.
      - gauravphoenix 8y ago
        if you want just simple layer 4 ACLs among the services, I recommend just using NetworkPolicies[1] of k8s. Personally, I think that Istio is overly complex but then so is k8s :) [1] https://kubernetes.io/docs/concepts/services-networking/network-policies/ https://kubernetes.io/docs/concepts/services-networking/netw...
  - manigandham 8y ago
    More protocol support, retries, rate-limits, circuit-breakers, traffic mirroring, better load-balancing, faster proxy performance, complex routing, fine-grained security policies with pluggable authentication, and in-depth monitoring with integrated tracing. Smaller clusters or services don't need it. The docs overview page is worth a read: https://istio.io/docs/concepts/what-is-istio/ https://istio.io/docs/concepts/what-is-istio/
    - jsmeaton 8y ago
      Thanks! I was wondering if mesh effectively replaces services and why, and you've answered that.

manigandham 8y ago

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.

jeremyjh 8y ago
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?
- gauravphoenix 8y ago
  things like layer 7 control, you can say - "don't allow HTTP GET on /supersecret". Also, Isito is gRPC aware
  - andrewstuart2 8y ago
    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.
    - gauravphoenix 8y ago
      if you want just simple layer 4 ACLs among the services, I recommend just using NetworkPolicies[1] of k8s. Personally, I think that Istio is overly complex but then so is k8s :) [1] https://kubernetes.io/docs/concepts/services-networking/network-policies/ https://kubernetes.io/docs/concepts/services-networking/netw...
- manigandham 8y ago
  More protocol support, retries, rate-limits, circuit-breakers, traffic mirroring, better load-balancing, faster proxy performance, complex routing, fine-grained security policies with pluggable authentication, and in-depth monitoring with integrated tracing. Smaller clusters or services don't need it. The docs overview page is worth a read: https://istio.io/docs/concepts/what-is-istio/ https://istio.io/docs/concepts/what-is-istio/
  - jsmeaton 8y ago
    Thanks! I was wondering if mesh effectively replaces services and why, and you've answered that.