Scalability and Rollback Efficiency of Kubernetes Deployment Patterns: A Study of Blue-Green vs. Canary Approaches

43 International Journal of Advance and Applied Research www.ijaar.co.in ISSN – 2347-7075 Impact Factor – 8.141 Peer Reviewed Bi-Monthly Vol. 6 No. 38 September - October - 2025 Scalability and Rollback Efficiency of Kubernetes Deployment Patterns: A Study of Blue-Green vs. Canary Approaches Amit K. Mogal1 & Vaibhav P. Sonaje2 1Department of Computer Science and Application, MVP Samaj’s Commerce, Management and Computer Science (CMCS) College, Nashik, Maharashtra, India. 2Department of Computer Science and Application, School of Computer Science and Engineering, Sandip University, Nashik, Maharashtra, India Corresponding Author – Amit K. Mogal DOI - 10.5281/zenodo.17309883 Abstract: In cloud-native software development, continuous deployment strategies significantly influence application availability, reliability, and maintainability. This study presents a comparative analysis of two widely adopted Kubernetes deployment patterns—Blue-Green and Canary—focusing on their scalability, rollback efficiency, and resource utilization in microservices-based web applications. Using a controlled Kubernetes environment, traffic simulations were executed via K6 to replicate real-world load scenarios, including linear ramp-ups, burst loads, and sustained user concurrency. Key performance metrics such as pod startup time, request latency (P50, P90, P99), CPU/memory utilization, and rollback duration were collected and analyzed using Prometheus and Grafana dashboards. Results show that while Blue-Green deployments offer faster rollback and simpler version control, Canary deployments provide finer traffic control and greater fault isolation during incremental releases. The findings highlight critical trade-offs in deployment strategy selection and provide operational insights for DevOps teams seeking to optimize reliability and service continuity in Kubernetes clusters. The study contributes to deployment automation best practices and supports informed decision-making for scalable, resilient microservice delivery pipelines. Keywords: Kubernetes, Microservices, Blue-Green Deployment, Canary Deployment, Continuous Delivery. Introduction: The evolution of software delivery has been profoundly influenced by the rise of microservices architecture and the advent of container orchestration platforms like Kubernetes. In today’s fast-paced development landscape, continuous integration and continuous deployment (CI/CD) practices are essential to achieving rapid, reliable software delivery. Within this context, deployment strategies play a critical role in ensuring that new software versions can be rolled out efficiently, without disrupting user experience or compromising system stability. Two of the most widely used deployment patterns in Kubernetes-based environments are BlueGreen deployments and Canary deployments, each offering unique advantages and trade-offs in terms of scalability, fault tolerance, and rollback capabilities. Blue-Green deployment is a wellestablished technique in which two identical environments—referred to as "blue" and "green"—are maintained. The live environment serves the current production traffic, while the new version is deployed to IJAAR Vol. 6 No. 38 ISSN – 2347-7075 Amit K. Mogal & Vaibhav P. Sonaje 44 the idle environment. After successful validation, the router or load balancer switches traffic to the new version, allowing instant rollback by reverting traffic to the previous environment in case of failure. This strategy provides a high degree of control and immediate rollback capability but comes at the cost of duplicating infrastructure and potential underutilization of resources. On the other hand, Canary deployment involves releasing the new version incrementally to a subset of users or traffic while the majority continues to interact with the stable release. This gradual rollout enables real-time monitoring of performance and error rates, allowing teams to detect and respond to issues before the full deployment. While this method enhances fault isolation and reduces the risk of full-scale failures, it introduces complexity in traffic management and requires robust observability to be effective. Kubernetes, as a container orchestration platform, provides native support and extensibility for implementing these deployment strategies through services, ingress controllers, and custom resource definitions (CRDs). However, the practical efficiency of Blue-Green and Canary deployments in Kubernetes environments— particularly in terms of scalability under high user load and rollback performance during failure scenarios—remains an area that demands empirical validation. As organizations adopt microservices at scale, understanding the operational impact of these deployment patterns is crucial for maintaining service availability and performance. This study seeks to address this gap by conducting a comprehensive comparative analysis of Blue-Green and Canary deployment approaches in Kubernetes, focusing specifically on their scalability and rollback efficiency. A series of controlled experiments were conducted using a microservices-based web application deployed in Kubernetes, subjected to simulated load patterns generated using K6, a modern performance testing tool. Metrics such as CPU and memory utilization, pod startup time, request latency across percentiles (P50, P90, P99), rollback duration, and autoscaling behavior were captured through Prometheus and Grafana monitoring stacks. The primary objective of this research is to evaluate which deployment pattern offers superior performance and resilience under various stress conditions, and how these approaches can be optimized to meet the demands of realtime, large-scale web applications. The findings of this study provide valuable insights for DevOps engineers, cloud architects, and software teams seeking to improve the reliability, efficiency, and fault recovery of their deployment pipelines in Kubernetes environments. This study aims to compare the performance of Blue-Green and Canary deployment strategies in Kubernetes environments under various traffic loads, including linear, burst, and sustained traffic. Additionally, it evaluates the rollback efficiency of both strategies by simulating controlled failure scenarios to assess their reliability and responsiveness. Ultimately, the research seeks to determine which deployment strategy offers superior scalability, lower latency, and more resource-efficient rollback behavior, providing valuable insights for optimizing Kubernetes cluster performance and reliability. By systematically analyzing deployment outcomes under consistent workload scenarios, this research contributes to the ongoing discourse on best practices in cloud-native deployment automation, offering a data-driven foundation for making strategic decisions about deployment methodologies in production Kubernetes environments IJAAR Vol. 6 No. 38 ISSN – 2347-7075 Amit K. Mogal & Vaibhav P. Sonaje 45 Related Work: The advancement of microservices architecture and the widespread adoption of Kubernetes have brought a paradigm shift in application deployment strategies. Among the most prominent methods for achieving continuous deployment and zero-downtime delivery are Blue-Green and Canary deployments. These techniques have been extensively explored in both industry and academia, particularly in relation to performance, scalability, rollback efficiency, and risk mitigation. James and Gideon (2024) conducted a comprehensive evaluation of Blue-Green and Canary deployments across multiple axes, including scalability, fault tolerance, and monitoring overhead. Their study highlighted that Blue-Green deployments offer a more straightforward rollback mechanism by switching traffic between production and staging environments but come at the cost of duplicating resources. In contrast, Canary deployments provide granular traffic control and real-time error detection, albeit requiring robust observability to ensure safety and effectiveness during progressive rollouts. In enterprise-level Kubernetes environments, Prabu (2024) emphasized the architectural differences and implications of using Blue-Green versus Canary deployments. He found that Blue-Green approaches simplify deployment for stateful applications due to fixed routing but tend to introduce inefficiencies when applied to dynamic microservices, especially under high concurrency. Conversely, Canary deployments demonstrated superior adaptability in autoscaling scenarios, thanks to Kubernetesnative integrations like custom metrics APIs and service mesh routing (e.g., Istio). Vangala (2025) compared the two strategies specifically within the context of DevOps workflows. His study concluded that Canary deployments outperform Blue-Green in terms of system resilience and latency management during high-load testing phases, especially when rollback needs to be partial or selective. Blue-Green’s instant rollback was found to be more efficient only in controlled, low-traffic scenarios where full-system switches are viable. Additional work by Idowu (2024) evaluated rollback time, error rates, and system recovery across Blue-Green and Canary strategies using Kubernetes and Istio. His findings aligned with prior research, reinforcing that Canary deployment allows for early anomaly detection and incremental failure isolation, which is especially critical in large-scale CI/CD pipelines where downtime can have cascading effects. His study also emphasized the importance of observability frameworks like Prometheus and Grafana in ensuring safe canary releases. Deployment rollback mechanisms in complex pipelines were further investigated by William and Mercy (2025), who explored how rollback logic is handled across different tools, including Kubernetes, ArgoCD, and Spinnaker. They noted that while both BlueGreen and Canary deployments support rollback procedures, the underlying trigger and execution mechanisms differ significantly. In Blue-Green, rollback is deterministic and switch-based; in Canary, rollback is often event-driven and influenced by real-time performance telemetry. In terms of scalability, Rakshit and Banerjee (2024) performed benchmarking experiments on Kubernetes clusters under variable loads using both deployment models. They concluded that Canary deployments scale more predictably when combined with Horizontal Pod Autoscalers (HPA) and custom metrics, while Blue-Green deployments IJAAR Vol. 6 No. 38 ISSN – 2347-7075 Amit K. Mogal & Vaibhav P. Sonaje 46 exhibited delayed resource stabilization due to abrupt traffic shifting. A significant contribution from Reid and James (2025) involved automating both Blue-Green and Canary deployment pipelines using Terraform. Their work demonstrated that infrastructureas-code tools could reduce human error and promote repeatability in deployment strategies. They found that Canary models benefited more from dynamic templating and modular infrastructure due to their progressive nature and need for granular control. In the realm of CI/CD optimization, Amgothu (2024) focused on integrating canary and blue-green strategies into CI pipelines using Jenkins and GitLab CI. His experiments showed that Canary deployments resulted in fewer production rollbacks when integrated with performance alerting and anomaly detection systems, thus reducing overall MTTR (mean time to recovery). Finally, the work by Sun-Rise (2025) in a productiongrade site reliability engineering (SRE) context emphasized that the combination of progressive deployment models with automated rollback mechanisms provides the most robust deployment reliability. His analysis showed that Blue-Green is optimal for controlled releases, while Canary excels in high-velocity, frequent deployments. Research Methodology: This study adopts an experimental research design to evaluate and compare the scalability and rollback efficiency of two Kubernetes deployment strategies: Blue-Green and Canary. The objective is to simulate realworld traffic loads, collect performance metrics, and analyze how each deployment strategy responds under varying conditions within a controlled Kubernetes environment. Experimental Environment Setup: Table 1. Environmental Setup for Experiment. Component Description Platform Kubernetes v1.24 running on Minikube and AWS EKS (for scalability validation) Application Web-based microservice (Node.js backend + React frontend + MongoDB) CI/CD Tool GitLab CI with integration to ArgoCD and Helm Traffic Generator K6 – for simulating realistic load patterns Observability Tools Prometheus, Grafana, and Loki (for logs, metrics, and alerts) Service Mesh Istio (for traffic routing and Canary rollout control) Deployment Patterns Under Study: Blue-Green deployment involves deploying a new version of an application in parallel with the existing version. Once the new version is validated, traffic is shifted entirely to the new version. One of the key benefits of this approach is the ability to perform instant rollbacks by simply switching traffic back to the previous version if any issues arise. In contrast, Canary deployment follows a more gradual approach, where a new version is rolled out to a small percentage of IJAAR Vol. 6 No. 38 ISSN – 2347-7075 Amit K. Mogal & Vaibhav P. Sonaje 47 traffic initially, such as 10% or 25%. The deployment is closely monitored for key metrics like error rates and latency before incrementally increasing the exposure to more users. If any predefined thresholds are breached, the deployment can be rolled back to ensure minimal impact on users. This approach allows for more controlled and riskaverse deployments. Workload Simulation Strategy: Traffic patterns were simulated using K6 to mimic real-world conditions as shown in Table 2 below Table 2. Workload Simulation for Experiment. Load Type Details Linear Ramp-Up Gradual increase from 10 → 200 users over 10 minutes Burst Load Sudden spike to 500 concurrent users Sustained Load 150+ concurrent users over a 15-minute window Metrics Collected: The study evaluated several key metrics across multiple categories, including: 1. Scalability: CPU utilization, memory usage, pod startup time, and pod count under Horizontal Pod Autoscaling (HPA). 2. Performance: Request latency (P50, P90, P99) and error rates. 3. Rollback Efficiency: Time to rollback and number of failed requests during rollback. 4. System Throughput: Requests per second (RPS) and success rate. 5. Cost Efficiency: Resource utilization versus workload served. These metrics provide a comprehensive understanding of the performance, scalability, and efficiency of the deployment strategies. Failure Injection & Rollback Testing: To evaluate rollback efficiency, deliberate faults were introduced during deployment, including: 1. CPU saturation using synthetic compute-bound loads to simulate resource exhaustion. 2. Forced application errors through bad configuration or HTTP 500 errors to mimic real-world failures. 3. Monitoring thresholds, such as error rates exceeding 2% or latency above 500ms, were set to trigger rollbacks automatically via ArgoCD and Istio routing policies. These fault injection scenarios allowed for assessing the responsiveness and effectiveness of the rollback mechanisms in both Blue-Green and Canary deployment strategies. Data Collection Tools and Logging: The study utilized several tools for monitoring and metrics collection: 1. Prometheus: Collected CPU, memory, and pod metrics. 2. Grafana: Provided dashboards to visualize metric evolution over time. 3. Loki: Aggregated logs to detect errors and rollback events. 4. K6 Output JSON: Used to extract detailed latency distributions and throughput metrics. These tools enabled comprehensive monitoring and analysis of the deployment strategies' performance. IJAAR Vol. 6 No. 38 ISSN – 2347-7075 Amit K. Mogal & Vaibhav P. Sonaje 48 Experimental Procedure: The experiment consisted of several key steps: 1. A baseline test was conducted by deploying a stable version using both Blue-Green and Canary strategies, measuring the idle overhead for each. 2. Traffic simulation was then performed, introducing loads according to a predefined scenario matrix. 3. A rollback scenario was triggered mid-deployment, simulating a fault and measuring the response time and system impact. 4. To ensure consistency, each scenario was executed three times, and the average results were used for analysis. 5. Results were logged in JSON format and Grafana snapshots, facilitating detailed post-analysis and comparison of the two deployment strategies. Validity & Reliability Measures: To ensure a fair and reliable comparison, the experiment utilized identical cluster configurations and system baselines for both deployment strategies. The trials were repeated to minimize the impact of random fluctuations, and the results were validated using live metrics and structured logging. This approach enabled reproducibility and accuracy in the findings, providing a solid foundation for comparing the performance of Blue-Green and Canary deployment strategies Result, Analysis and Discussion: This section presents the experimental findings comparing Blue-Green and Canary deployment strategies in Kubernetes environments, focusing on key performance metrics such as scalability, resource utilization, rollback efficiency, and system throughput under simulated workloads. The results provide insights into the strengths and limitations of each strategy, highlighting their suitability for different use cases and environments. By analyzing these metrics, this study aims to inform best practices for deploying applications in Kubernetes, ultimately enhancing system reliability, efficiency, and performance. Scalability Metrics: Our results provide insights into the strengths and weaknesses of each strategy, informing decisions on optimal deployment approaches in cloud-native applications. Table 3. CPU and Memory Utilization Time (min) Cluster 1 (Blue-Green) Cluster 2 (Canary) CPU Peak 74% 62% Memory Peak (MiB) 5571 MiB 4505 MiB Canary deployments demonstrated superior resource efficiency compared to BlueGreen deployments, exhibiting lower CPU and memory usage due to their progressive rollout and gradual pod scaling. In contrast, BlueGreen deployments resulted in abrupt resource provisioning, leading to notable resource spikes and inefficient pod utilization during traffic switching. This comparison yields a key insight: Canary deployment offers better resource elasticity, effectively avoiding system saturation during peak loads. By adopting a more gradual approach to deployment, Canary deployments minimize the strain on system resources, ensuring more efficient and reliable performance under varying loads. IJAAR Vol. 6 No. 38 ISSN – 2347-7075 Amit K. Mogal & Vaibhav P. Sonaje 49 Table 4. Pod Startup Time and Autoscaling Responsiveness Scenario Blue-Green Canary Cold Start (avg) 10.2s 7.4s Autoscaling Response 5 pods in 10 min 6 pods in 6 min When paired with Horizontal Pod Autoscaling (HPA) and metric-based triggers, Canary deployment enabled faster scaling decisions, allowing for more agile responses to changing traffic conditions. In contrast, BlueGreen deployment required a full set of pods to be ready before switching traffic, which introduced delays in readiness and increased startup latency. This highlights a key advantage of Canary deployment: its ability to provide finer control over rollout velocity and scaling policies, making it more responsive to dynamic traffic surges. By leveraging this flexibility, Canary deployment can better adapt to fluctuating demands, ensuring more efficient and responsive system performance. Table 5. Request Latency and Tail Performance Request Rate (req/sec) Latency (P50) Latency (P90) Latency (P99) Blue-Green 190ms 310ms 470ms Canary 140ms 210ms 260ms Canary deployments consistently maintained lower latency across all percentiles, particularly under burst and sustained loads, demonstrating its ability to handle traffic demands efficiently. In contrast, Blue-Green deployments experienced significantly higher latency, with P99 latency nearly 80% higher, highlighting poor tail-end performance during load shifts. This disparity underscores the benefits of Canary's incremental rollout approach, which helps isolate faults and stabilize latency. By gradually introducing changes, Canary deployments minimize the risk of overwhelming the cluster, ensuring more consistent and reliable performance. In contrast, Blue-Green's all-or-nothing approach can lead to performance degradation during traffic switches. Table 6. Rollback Efficiency Metric Blue-Green Canary Rollback Time 6.5 seconds 9.2 seconds Failed Requests During Rollback 18% spike <5% spike Blue-Green deployments enabled near-instant rollbacks by simply switching traffic routes, offering a speedy recovery option. However, Canary deployments, IJAAR Vol. 6 No. 38 ISSN – 2347-7075 Amit K. Mogal & Vaibhav P. Sonaje 50 although slightly slower in rollback, demonstrated a significant advantage in minimizing failed requests. This was achieved through real-time metric-triggered rollbacks applied to a partial subset of traffic, ensuring a more controlled and safer reversal process. The insight here is that while Blue-Green rollbacks are faster, they can be riskier without proper monitoring. In contrast, Canary rollbacks, though slightly slower, are inherently safer and more fault-tolerant, making them particularly suitable for real-time systems where reliability and precision are crucial. Table 7. Throughput and Load Handling Scenario Blue-Green (req/sec) Canary (req/sec) Sustained Load 140 req/sec 190 req/sec Burst Load Handling Delayed Stable at 170+ Canary deployment demonstrated superior sustained throughput, particularly when integrated with KEDA (event-based autoscaler) and Istio for routing. This combination allowed for efficient handling of traffic demands. In contrast, Blue-Green deployment struggled to stabilize after abrupt traffic shifts, resulting in brief periods of throughput degradation. The key insight is that Canary deployment supports high-velocity continuous delivery and handles event-driven loads more gracefully. By gradually introducing changes and scaling resources accordingly, Canary ensures a more stable and efficient system performance, making it wellsuited for environments with dynamic traffic patterns. The results conclusively show that Canary deployments, despite their more complex setup, outperform Blue-Green deployments in Kubernetes environments in terms of scalability, resilience, and rollback control. While Blue-Green deployments are well-suited for specific use cases such as lowfrequency full system updates or scenarios requiring instant full rollback, Canary deployments are more adaptable to modern, dynamic environments. Canary's strengths make it particularly suitable for real-time microservices, frequent code delivery, and data-driven Site Reliability Engineering (SRE) environments, where observability and progressive rollout are essential. By leveraging Canary's capabilities, teams can achieve more reliable and efficient deployments, better aligning with the demands of contemporary software development and operations. Limitations and Future Research: This study, despite its comprehensive nature, is subject to several limitations that warrant acknowledgment. Firstly, the experiments were conducted in a controlled Kubernetes cluster with simulated traffic, which may not fully replicate the complexities of real-world production environments where factors like network latency and inter-service dependencies play a role. Additionally, the study's focus on stateless microservices limits its generalizability to stateful services or applications with different transactional dynamics. The reliance on specific tools like Istio and Prometheus may also introduce bias, as alternative configurations could yield different outcomes. Furthermore, the shortterm observation window may overlook longterm performance implications such as memory leaks or autoscaler recalibration. IJAAR Vol. 6 No. 38 ISSN – 2347-7075 Amit K. Mogal & Vaibhav P. Sonaje 51 Finally, the single-cluster setup does not account for the complexities of multi-region or hybrid cloud deployments, where network latency and routing could impact deployment strategy effectiveness. These limitations highlight areas for future research to further validate and extend the findings. Future research directions building upon this study's findings could explore several key areas. Firstly, evaluating BlueGreen and Canary deployments in multicluster and edge environments would provide insights into their performance under geographically distributed scenarios. Secondly, integrating AI/ML-driven autoscalers could optimize rollout and rollback processes. Thirdly, investigating the impact of these deployment patterns on stateful and streaming applications would be valuable. Additionally, examining security and compliance considerations, developing cost optimization models, and exploring human-inthe-loop rollback strategies could further enhance the understanding and application of these deployment strategies in real-world contexts Conclusion: The evolution of microservices and cloud-native architectures has made deployment strategies a critical component of system reliability, performance, and agility. This research undertook a comprehensive comparative study of two widely adopted Kubernetes deployment models—Blue-Green and Canary—with a specific focus on their scalability, rollback efficiency, and operational resilience. Through a series of controlled experiments involving simulated workloads, traffic spikes, and induced failure scenarios, the study revealed that Canary deployments offer superior scalability and fault isolation, particularly in dynamic and high-concurrency environments. Canary's gradual rollout mechanism, when paired with real-time telemetry and autoscaling logic, allowed for more adaptive system behavior and lower tailend latency. Although rollbacks in Canary deployments were slightly slower than in Blue-Green, they were more targeted and resulted in fewer service disruptions. In contrast, Blue-Green deployments excelled in environments where simplicity, predictability, and full rollback speed were more critical than resource efficiency. Their ease of setup and binary traffic switching model made them well-suited for monolithic or low-frequency release pipelines. However, they incurred higher infrastructure overhead due to environment duplication and showed limitations under burst and sustained traffic loads. Ultimately, the study demonstrates that neither strategy is universally superior, but rather, the optimal choice depends on the deployment context, risk tolerance, and observability maturity of the organization. For teams prioritizing fine-grained control, progressive delivery, and minimal blast radius, Canary deployment is the preferred model. For organizations requiring rapid full-system switches with limited infrastructure complexity, Blue-Green remains a viable option. This work contributes to the ongoing discourse on DevOps and cloud-native deployment best practices by providing datadriven insights, real-world metrics, and empirical comparisons between deployment strategies. It also lays a foundation for future exploration into multi-cluster, AI-enhanced autoscaling, and hybrid deployment models that can further optimize the balance between speed, safety, and efficiency in modern application delivery pipelines.