{"id":275,"date":"2017-05-25T04:09:53","date_gmt":"2017-05-25T04:09:53","guid":{"rendered":"https:\/\/blog.ngocha.biz\/?p=275"},"modified":"2017-05-25T04:09:53","modified_gmt":"2017-05-25T04:09:53","slug":"istio-opensource-platform-microservices-management","status":"publish","type":"post","link":"https:\/\/blog.ngocha.biz\/?p=275","title":{"rendered":"What is Istio? What Does it Solve?"},"content":{"rendered":"

Istio<\/a> started as a collaboration among three companies, Google, IBM, and Lyft <\/strong>to develop an open cloud service to connect, secure, manage and monitor a network of microservices regardless of platform, source or vendor.<\/p>\n

In this blog, you will learn what Istio is, why it is used, and the problems it solves like traffic management, security, observability, and service-to-service communication in Kubernetes.<\/p>\n

What is Istio?<\/h2>\n

Containerization<\/a> has made microservices deployments simple and easier and the adoption of microservices is increasing day by day. Microservices architecture allows the developers to decouple a big application into smaller units and these smaller units talk to each other using API’s.<\/p>\n

Also, each microservice can be deployed by teams individually rather than waiting for the whole application to be developed for deployment.<\/p>\n

Managing these microservice on a large scale poses the following challenges <\/p>\n

    \n
  1. Discovering services – <\/strong>Finding a healthy service to route the traffic<\/li>\n
  2. Balancing the request load – <\/strong>Evenly distribute the traffic across services<\/li>\n
  3. Security – <\/strong>Ensuring the communication is encrypted and that the allowed services only communicate.<\/li>\n
  4. Controlling Traffic <\/strong>– Routing traffic to new services using methods such as Canary.<\/li>\n
  5. Handling Failures – <\/strong>Controlling retries for the failed requests and preventing failures.<\/li>\n
  6. Monitoring<\/strong> – Tracking the performance and failures by logs, metrics, and traces.<\/li>\n<\/ol>\n

    Here is where Istio comes in to play.<\/p>\n

    Istio helps us solve the difficulties by acting as an infrastructure layer to manage the communication between services. You can call it a service mesh.<\/p>\n

    \n
    \ud83d\udca1<\/div>\n
    A service mesh<\/strong><\/b> is a dedicated infrastructure layer<\/strong><\/b> within the platform that manages service-to-service communication<\/strong><\/b>.<\/div>\n<\/div>\n

    Istio works very closely with the services using lightweight proxies<\/strong> to handle the traffic.<\/p>\n

    \n
    \ud83d\udca1<\/div>\n
    The original Istio architecture is Sidecar, which means a proxy runs alongside each pod. Recently, they have introduced a new method called Ambient Mode which does not run as sidecar.<\/div>\n<\/div>\n

    Also, the only supported platform for Istio is Kubernetes<\/a>.<\/p>\n

    Core Features of Istio<\/h2>\n

    The following are some of the important features of Istio.<\/p>\n

    1. Traffic Control<\/h3>\n

    Istio has the Custom Resource Definitions (CRDs)<\/strong> to configure the settings to define how the traffic should flow.<\/p>\n

    The routing rules in Istio are configured using the Virtual Service<\/strong> Custom Resource.<\/p>\n

    In Virtual Service, we can control the traffic based on.<\/p>\n

      \n
    1. Host<\/li>\n
    2. Path <\/li>\n
    3. Headers <\/li>\n
    4. Labels<\/li>\n<\/ol>\n

      We can even split the traffic between different service versions to perform Canary or A\/B testing, which means we can control how much traffic should be routed to each service.<\/p>\n

      \n
      \ud83d\udca1<\/div>\n
      We can perform chaos engineering<\/strong><\/b> using Istio’s fault injection<\/strong><\/b>. This allows us to add intentional delays and errors in requests to validate the stability and resilience of our system.<\/div>\n<\/div>\n

      Another Custom Resource of the Istio is the Destination Rule, <\/strong>which allows us to configure the following settings.<\/p>\n

        \n
      1. Timeout<\/strong> – How long should we wait for a request to resolve<\/li>\n
      2. Retries<\/strong> – How many times does a request need to be retried for a failed request<\/li>\n
      3. Circuit Breaking<\/strong> – What should you do if a service endpoint is unhealthy.<\/li>\n
      4. Connection Pooling<\/strong> – How much traffic should be routed on a service.<\/li>\n<\/ol>\n

        2. Security<\/h3>\n

        Istio uses strong cryptographic identities to ensure secure and encrypted communication between the services. (Follows SPIFFE<\/strong> framework and X.509 certificates)<\/p>\n

        Here, the Control Plane (Istiod) acts as a Certificate Authority (CA) to generate and manage the certificates. The data planes perform the mTLS handshake to ensure the identity.<\/p>\n

        Authorization Policy <\/strong>is another CRD that defines who should access the services.<\/p>\n