SaFi Bank Space : Istio

What is Istio?

Istio is an open service mesh that provides a uniform way to connect, manage, and secure microservices. It supports managing traffic flows between services, enforcing access policies, and aggregating telemetry data, all without requiring changes to the microservice code.

Istio gives you the following benefits:

• Automatic load balancing for HTTP, gRPC, WebSocket, MongoDB, and TCP traffic.

• Fine-grained control of traffic behavior with rich routing rules, retries, failovers, and fault injection.

• A configurable policy layer and API that supports access controls, rate limits, and quotas.

• Automatic metrics, logs, and traces for all traffic within a cluster, including cluster ingress and egress.

• Secure service-to-service communication in a cluster with strong identity-based authentication and authorization.

Istio is designed for extensibility and can handle a diverse range of deployment needs. Istio’s control plane runs on Kubernetes, and you can add applications deployed in that cluster to your mesh, extend the mesh to other clusters, or even connect VMs or other endpoints running outside of Kubernetes.

A large ecosystem of contributors, partners, integrations, and distributors extend and leverage Istio for a wide variety of scenarios. You can install Istio yourself, or a number of vendors have products that integrate Istio and manage it for you.

Istio addresses the challenges developers and operators face with a distributed or microservices architecture. Whether you're building from scratch or migrating existing applications to cloud-native, Istio can help.

1. Traffic Management

2. Security

3. Observability

Traffic Management:

• Gateways

• Virtual service

• Destination rules

• Subsets

• Timeouts

• Retries

• Circuit Breaking

• Fault Injection

• Request Routing

• A/B Testing

Security

• Authentication

• Authorization

• Certificate Management (mTLS)

Observability

• Visualizing Metrics with Prometheus and Grafana

• Distributed Tracking with Jaeger

• Kiali Dashboard

Indications of Service Mesh Need

• Service Sprawl - tons of micro-service deployed with no centralization of management, unknown utilization and health.

• It is a dedicated and configurable infrastructure layer that handles the communication between services without having to change the code in a microservice architecture.

• Release Bottlenecks Deployments - Dark launches, blue/green, custom traffic for specific feature

Cons Of Service Mesh:

• Cost - Istio is fundamentally free but running additional compute power to run the platform can be costly.

• Learning Curve - Is not very steep in terms of learning but it is something to consider specially with all the techs to be integrated with kubernetes cluster can be daunting.

Explanation with Sample Application:

How it Works

Istio has two components: the data plane and the control plane.

The data plane is the communication between services. Without a service mesh, the network doesn’t understand the traffic being sent over, and can’t make any decisions based on what type of traffic it is, or who it is from or to.

Service mesh uses a proxy to intercept all your network traffic, allowing a broad set of application-aware features based on configuration you set.

An Envoy proxy is deployed along with each service that you start in your cluster, or runs alongside services running on VMs.

The control plane takes your desired configuration, and its view of the services, and dynamically programs the proxy servers, updating them as the rules or the environment changes.

Traffic Management:

Kubernetes Way Istio Way

Security:

Observability:

How To do:

• What is Istio and difference does it make to have it in cluster?

  • Istio is an open source service mesh that layers transparently onto existing distributed applications. Istio’s powerful features provide a uniform and more efficient way to secure, connect, and monitor services. Istio is the path to load balancing, service-to-service authentication, and monitoring – with few or no service code changes.

• What are major benefits of having Istio in cluster?

  • Traffic Management

  • Security

  • Observability

• What overhead does it bring?

  • Additional computation in terms of CPU and Memory

  • Additional kube resources needs to be deployed, like gateway and virtual services

  • Virtual services should be reviewed properly

• How can it be deployed to cluster?

  • istioctl will be easiest way

  • helm installation available

  • Istio operator (new recommended way)

  • Deployment Types(Need more understanding):

    • Single or Multiple Cluster

    • Single or Multiple network

    • Single or multiple control plane

    • Single or multiple mesh

  • Reference: https://istio.io/latest/docs/ops/deployment/deployment-models/

• What needs to be changed in Vanilla GKE in order for Istio work properly?

  • Namespace should be istio label injected before deploying applications

  • Better to use Istio Ingress gateway

  • Need to decide TLS on the cluster level or namespace level

• Is the default CNI going to work with Istio?

  • Will not affect, Since Istio/envoy proxy running as sidecar container and sharing same network namespace.

• What is overhead of running Istio?

  • Need clarification

• How is the Istio managed? Terraform? ArgoCD?

  • Istio Operator can be installed via ArgoCD

  • Using Istio operator, Istio can be installed via ArgoCD

• How is Istio going to be backedup? Is there something to be backed up?

  • No, Istio CRDs can be reinstalled

  • Note: All our rules and policies are deployed via helm(ArgoCD) and should be available in GIT as well.

• What needs to be changed in application in order for it to work with Istio?

  • No change on the application side deployment, how ever resources should have “app” label for kiali dashboard to work properly.

• Is it going to change way how we deploy applications?

  • Virtual service and gateway should be created during deployment itself.

• Do developers need to have istioctl installed?

  • No

• Do devops need to have istioctl installed?

  • No, Istioctl may be useful for troubleshooting.

• How is the security going to be enforced?

• How is the traffic management going to be configured?

  • Via virtual service, please refer above diagrams

• Is the proposed log collecting solution going to work with Istio?

  • Yes, it’s just sidecar container applicable same as application log collection method.

• How is the traffic going to enter the Istio mesh?

  • Istio ingress controller?

    • Yes for external traffic via ingress gateway and virtual service, for internal traffic will be via virtual service

  • Nodeports?

    • NA

  • GCP (private) loadbalancers?

    • NA

• Is there going to be some Admin UI?

  • Configuration can be viewed via Kiali dashboard but need to explore on the RBAC.

• How is the UI going to be accessed?

  • Need to explore

• How is the Istio going to be monitored, with proposed monitoring solution?

  • prometheus and grafana for visulisation

  • Zipkin/Jaegar for distributed traffic tracing

  • Kiali for traffic metrics and troubleshooting

• Do containers need to have sidecars all the time?

  • Yes.

Ref: SM-1250 - Breakdown of Istio Resolved