{"id":74392,"date":"2025-12-10T16:43:19","date_gmt":"2025-12-10T11:13:19","guid":{"rendered":"https:\/\/www.tothenew.com\/blog\/?p=74392"},"modified":"2026-01-27T13:10:17","modified_gmt":"2026-01-27T07:40:17","slug":"kubernetes-deployment-using-istio-service-mesh","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/kubernetes-deployment-using-istio-service-mesh\/","title":{"rendered":"Kubernetes Deployment using Istio Service Mesh"},"content":{"rendered":"

Introduction<\/strong><\/p>\n

Modern applications need zero-downtime deployments and safe rollouts. Blue-Green Deployment is a classic strategy where two environments (Blue = current version, Green = new version) exist side by side, and traffic is gradually shifted. When paired with Istio Service Mesh, you get powerful traffic management features like routing traffic by percentage making Blue-Green safer and more flexible.<\/p>\n

In this post, we\u2019ll walk through how to set up a Blue-Green deployment on Kubernetes using Istio VirtualService to route traffic between versions.<\/p>\n

Problem Statement<\/h2>\n

In modern microservices-based applications, deploying a new version of a service without impacting users is a major challenge. Traditional Kubernetes deployments often rely on rolling updates, which still carry risks such as partial outages, unexpected bugs in production, and limited control over traffic distribution. Additionally, without advanced traffic management, it becomes difficult to safely test new versions with a subset of users, instantly roll back faulty releases, or enforce secure service-to-service communication. As application scale and complexity grow, organizations need a more reliable, secure, and controlled deployment strategy that ensures zero downtime, fine-grained traffic routing, and instant rollback capability.<\/p>\n

Why Blue-Green with Istio?<\/strong><\/h2>\n

Traditional Blue-Green requires a hard cutover (switch all traffic at once). This can be risky if the new version has hidden issues. Istio enables progressive traffic shifting:
\nStart with 10% of users on Green.
\nMonitor metrics (latency, error rate).
\nGradually increase until Green takes 100%.
\nRoll back instantly if problems appear.
\nThis approach reduces deployment risk and improves reliability.<\/p>\n

<\/h1>\n
\"Minikube\"

Minikube<\/p><\/div>\n

<\/h1>\n

What is Istio<\/h2>\n

Istio\u00a0is\u00a0an open-source implementation of the service mesh\u00a0originally developed by IBM, Google, and Lyft. It can layer transparently onto a distributed application and provide all the benefits of a service mesh like traffic management, security, and observability.
\nIt\u2019s designed to work with a variety of deployments, like on-premise, cloud-hosted, in Kubernetes containers, and in servicers running on virtual machines. Although\u00a0Istio is platform-neutral, it\u2019s quite often used together with microservices deployed on the Kubernetes platform.
\nFundamentally, Istio works by deploying an extended version of Envoy as proxies to every microservice as a sidecar.<\/p>\n

<\/h1>\n

Understanding Istio Components<\/h2>\n

1. Data Plane<\/h3>\n

The data plane of Istio is primarily built on an enhanced version of the Envoy proxy. Envoy is an open-source edge and service proxy that abstracts networking responsibilities away from application code. With Envoy in place, applications communicate only with localhost, remaining completely unaware of the underlying network topology.
\nAt its core, Envoy operates as a high-performance network proxy at Layer 3 and Layer 4 of the OSI model, using a chain of pluggable network filters to manage connections. In addition, Envoy provides Layer 7 (application-layer) filtering for HTTP-based traffic and offers first-class support for modern protocols such as HTTP\/2 and gRPC.<\/p>\n

Most of Istio\u2019s service mesh capabilities are directly powered by Envoy\u2019s built-in features:<\/p>\n

    \n
  • Traffic Control: Envoy enables fine-grained traffic management through advanced routing rules for HTTP, gRPC, WebSocket, and TCP traffic.<\/li>\n
  • Network Resiliency: It provides native support for automatic retries, circuit breaking, timeouts, and fault injection.<\/li>\n
  • Security: Envoy enforces security policies, implements access control, and supports rate limiting for secure service-to-service communication.<\/li>\n<\/ul>\n

    Another key strength of Envoy is its extensibility. It offers a flexible extension model based on WebAssembly (Wasm), which enables custom policy enforcement and advanced telemetry generation. Additionally, Istio further extends Envoy using Istio-specific extensions built on the Proxy-Wasm sandbox API, making it highly adaptable for advanced use cases.<\/p>\n

    2. Control Plane<\/h3>\n

    As discussed earlier, the control plane in Istio is responsible for managing and configuring the Envoy proxies that form the data plane. This responsibility is handled by istiod, which translates high-level traffic management and routing rules into Envoy-specific configurations and dynamically distributes them to the sidecar proxies at runtime.<\/p>\n

    In earlier versions of Istio, the control plane architecture consisted of multiple independent components working together. These included Pilot for service discovery and traffic management, Galley for configuration validation, Citadel for certificate generation, and Mixer for policy enforcement and telemetry. Over time, to reduce operational complexity and improve maintainability, these separate components were consolidated into a single unified component known as istiod.<\/p>\n

    Despite this unification, istiod continues to use the same core code and APIs that powered the original components. For example, the functionality previously handled by Pilot still abstracts platform-specific service discovery mechanisms and converts them into a standardized format that Envoy sidecars can consume. This enables Istio to support multiple environments, such as Kubernetes and virtual machines.<\/p>\n

    In addition to traffic management, istiod also provides strong security capabilities. It enables secure service-to-service and end-user authentication through built-in identity and credential management. Istiod can enforce security policies based on service identity and also functions as a Certificate Authority (CA). By issuing and managing certificates, it enables mutual TLS (mTLS) communication across the data plane, ensuring encrypted and authenticated traffic between services.<\/p>\n

     <\/p>\n

    \"Architecture

    Architecture – Istio Components<\/p><\/div>\n

    Setup and Step By Step Process<\/h2>\n
      \n
    1. Installing Minikube and istioctl<\/strong>\n

      $ sudo snap install minikube –classic
      \n$ curl -L https:\/\/istio.io\/downloadIstio | sh –
      \n$ cd istio-*
      \n$ sudo mv bin\/istioctl \/usr\/local\/bin\/<\/p>\n

      Then Next step ><\/li>\n<\/ol>\n

      \"istioctl\"

      istioctl<\/p><\/div>\n

      Label your Namespace ><\/p>\n

      \"Namespace\"

      Namespace<\/p><\/div>\n

      2. File Structure and Docker Build<\/strong><\/p>\n

      $ docker build -t blue-app app\/blue
      \n$ docker build -t green-app app\/green
      \n$ kubectl apply -f k8s\/
      \n$ kubectl apply -f istios\/<\/p>\n

       <\/p>\n

      \n

      \"File<\/p>\n

       <\/p>\n

      \"kubectl

      File Structure and Kubectl apply<\/p><\/div>\n

      3. Access The Application<\/strong><\/p>\n

      $ minikube tunnel
      \n$ kubectl get svc -n istio-system<\/p>\n

      \"minikube

      minikube tunnel<\/p><\/div>\n

       <\/p>\n

      \"kubectl

      kubectl services<\/p><\/div>\n

      Get the external IP from the Load Balancer service.
      \n10.99.215.231\u00a0 \u00a0(this is just a sample and does not contain any securty feature – we can use aws secuirty to mask endpoint or IPs of loadbalancer and other services)<\/p>\n

      4. Blue-Green Version Rollout<\/strong><\/p>\n

      We are making initially 70% traffic route for Blue version and 30% Green Version.
      \nChange the http section in virtual-service.yaml<\/p>\n

      \"virtual-service

      virtual-service file<\/p><\/div>\n

       <\/p>\n

      \"virtual-service\"

      virtual-service apply<\/p><\/div>\n

      Now we can verify that 3 traffic routes out of 10 are going to Green service.<\/p>\n

       <\/p>\n

      \"Traffic

      Traffic Routing<\/p><\/div>\n

      Traffic routing will be closer to 30 % for Green and 70% for Blue Service. (But it is not exact number.)<\/p>\n

       <\/p>\n

      \"Traffic

      Traffic Validation<\/p><\/div><\/blockquote>\n<\/div>\n

      Conclusion<\/h2>\n

      To address these challenges discussed in problem statement, this blog demonstrated how Blue-Green deployment combined with Istio Service Mesh provides a powerful, production-grade solution for zero-downtime application releases<\/strong>. By leveraging Istio VirtualService and DestinationRule, we achieved precise traffic routing with a 70\/30 split between Blue and Green versions, enabling safe progressive delivery and quick rollback in case of failure<\/strong>. Istio further enhances the deployment with built-in security (mTLS), traffic observability, and resiliency features, making deployments not only safer but also more intelligent. This approach mirrors how large-scale platforms like Netflix roll out changes with minimal risk, proving that service mesh\u2013based deployment strategies are essential for building reliable, scalable, and cloud-native applications.<\/strong><\/p>\n

      Please let me know in the comments if you were already aware about it? Do you want the advance details in next Blog?<\/p>\n","protected":false},"excerpt":{"rendered":"

      Introduction Modern applications need zero-downtime deployments and safe rollouts. Blue-Green Deployment is a classic strategy where two environments (Blue = current version, Green = new version) exist side by side, and traffic is gradually shifted. When paired with Istio Service Mesh, you get powerful traffic management features like routing traffic by percentage making Blue-Green safer […]<\/p>\n","protected":false},"author":2139,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":55},"categories":[5877],"tags":[7873],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/74392"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/2139"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=74392"}],"version-history":[{"count":14,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/74392\/revisions"}],"predecessor-version":[{"id":77551,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/74392\/revisions\/77551"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=74392"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=74392"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=74392"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}