Skip to main content

Documentation Index

Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt

Use this file to discover all available pages before exploring further.

Here’s your traditional home. You have a living room, a bathroom, a kitchen, and maybe a couple of bedrooms. In one room, two siblings might be playing video games while Grandma watches them. She gets a little cold, so she plugs in her heater. Adjacent on the other side of that wall, Mom just finished taking a shower and is drying her hair. Without getting too technical, too much power flowing through the wires can overheat them and potentially cause a fire. Luckily, your home has a circuit breaker.

​
What is a circuit breaker?

A circuit breaker is a safety switch. If a TV, gaming console, heater, and dryer all draw power from the same circuit, the current can exceed the circuit’s safe limit. The circuit breaker trips and cuts power to that part of the house, preventing an electrical fire. Circuit breakers literally save homes every day. Circuit breaking in Istio is similar to the circuit breaker in your house, but instead of electricity it controls network traffic between services. If one service is slow, overloaded, or failing, circuit breaking helps protect the rest of the system from being dragged down or overwhelmed. Let’s look at an example. Imagine your house has a hot-water system that serves the bathrooms, kitchen, and laundry. If all these fixtures request hot water at the same time, the hot-water service might get overwhelmed and fail to deliver hot water. To prevent this, you install a smart system like the Istio service mesh that implements circuit breakers. For example, if more than two taps ask for hot water at once, stop sending additional requests for a short period. The hot-water service stops accepting new requests until a tap is freed.
A schematic titled "House Example" showing rooms (kitchen, bath-01, bath-02, laundry, hot-water) as dashed boxes with service nodes labeled "...-svc" and Envoy proxy icons. Dashed arrows between the boxes indicate connection/traffic flows, with red dashed lines highlighting certain routes.
This is circuit breaking: preventing overload to keep the system healthy. A common microservices example is the Bookinfo application. The productpage communicates with services such as reviews and details. If the details service slows or fails, requests from productpage will pile up waiting for a response, creating delays. Instead of letting productpage wait indefinitely, we can fail fast or short-circuit those requests to prevent cascading latency.
A schematic architecture diagram for a "Book Info App" showing istio-ingress and virtual services routing to a Product Page and Details. The Reviews service branches into Reviews v1, v2, and v3 and connects to a Ratings service.
The Bookinfo diagram shows how one failing service can affect others. Now consider a simpler three-service example: homepage, product service, and a database. The product service talks to the database, and the homepage calls the product service. If the database becomes slow, the product service blocks waiting for responses, eventually timing out and retrying. Meanwhile the homepage becomes slow because it depends on product. This is a cascading failure: as more user requests arrive, the whole application becomes sluggish or may crash. Applying circuit breaking changes the behavior. Istio can detect that the database is slow or failing and trip a circuit breaker. The product service stops sending requests to the database for a short period and can return a quick failure response back to the homepage (for example, “out of stock” or an error). The homepage remains responsive and the system overall stays stable.
A simple diagram of an e-commerce site: a homepage and product page connected to a database. A circuit-breaker icon shows the database link cut, causing errors/“Out of Stock” on the site.
The system stays stable and users still get a working experience, even if some features are degraded. Without something like Istio’s circuit breaking, developers would need to build and maintain their own client-side logic to detect failures, throttle requests, and eject unhealthy endpoints. Istio centralizes this behavior in the mesh so developers can focus on application logic.

​
Why use circuit breaking?

Circuit breaking provides several operational and UX benefits. It helps keep services healthy, keeps latency bounded, and makes failures more visible and easier to manage.
BenefitWhat it does
Prevent cascading failuresStops repeated calls to a failing service so downstream callers don’t get overwhelmed
Protect healthy servicesPrevents healthy services from being drawn into failure by overloading them with retries or queued requests
Reduce load on failing servicesGives struggling services breathing room to recover by limiting incoming traffic
Improve user experienceFails fast and provides fallbacks instead of making users wait indefinitely
Easier debuggingCircuit trips make failures more visible and simpler to analyze
An infographic titled "Why Use Circuit Breaking?" with five numbered panels and icons. Each panel lists a benefit: prevents cascading failures; protects healthy services; reduces load on failing services; improves user experience; and makes issues easier to detect and fix.

​
How Istio implements circuit breaking

If you didn’t recall, circuit breaking in Istio is configured in a DestinationRule resource. The settings live under the trafficPolicy section — specifically connectionPool and outlierDetection. These options are part of the DestinationRule API and are not configured in a VirtualService. Here is a typical DestinationRule with connection pool and outlier detection settings: 
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: app-ds
  namespace: frontend
spec:
  host: app-svc
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 2
        connectTimeout: 30s
      http:
        http2MaxRequests: 2
        maxRequestsPerConnection: 10
    outlierDetection:
      consecutive5xxErrors: 3
      interval: 5s
      baseEjectionTime: 10m

​
Key fields explained

FieldMeaning
connectionPool.tcp.maxConnectionsLimit on concurrent TCP connections to the host.
connectionPool.tcp.connectTimeoutTimeout for establishing TCP connections.
connectionPool.http.http2MaxRequestsMaximum concurrent HTTP/2 streams (per connection).
connectionPool.http.maxRequestsPerConnectionMaximum requests per connection for HTTP/1.x clients.
outlierDetection.consecutive5xxErrorsNumber of consecutive 5xx responses before ejecting an endpoint.
outlierDetection.intervalHow often Envoy runs the outlier detection analysis.
outlierDetection.baseEjectionTimeInitial duration an endpoint is ejected for.
Study the DestinationRule options for connectionPool and outlierDetection. These are common certification topics and useful to understand in practice. Refer to the official docs for full option lists and behavior nuances.

​
Two real-world DestinationRule examples

Below are two practical DestinationRule examples with different tuning choices for reviews and a Redis service. 
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews-cb-policy
spec:
  host: reviews.prod.svc.cluster.local
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http2MaxRequests: 1000
        maxRequestsPerConnection: 10
    outlierDetection:
      consecutive5xxErrors: 7
      interval: 5m
      baseEjectionTime: 15m

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: bookinfo-redis
spec:
  host: myredissrv.prod.svc.cluster.local
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
        connectTimeout: 30s
        tcpKeepalive:
          time: 7200s
          interval: 75s

​
Tips and references

  • The DestinationRule docs list all available connectionPool and outlierDetection options — know where to find them: https://istio.io/latest/docs/reference/config/networking/destination-rule/
  • Certification exams typically include questions about circuit breaking and DestinationRule settings. Read the documentation so you can answer configuration and behavior questions confidently.
  • When tuning, start conservatively and monitor metrics (latency, error rates, ejection events) to adjust limits and timeouts.
Anyways, that covers the theory in this lesson/article. Let’s head over to a demo.

Watch Video