The Real Reason Your Istio Traffic Routing Fails? Mastering AND and OR Logic 🚀

Hello! When dealing with service meshes, especially Istio, in an MSA (Microservice Architecture) environment, you realize how crucial it is to control traffic as desired. When setting rules like “Send this request to service A, and that request to service B!”, we use VirtualService.

However, sometimes traffic doesn’t flow as intended. 🤔 It seems like the rules are set correctly. In many cases, the reason might be a lack of precise understanding of the logic Istio uses to interpret traffic matching rules.

Did you perhaps think that Istio’s matching rules only support OR conditions, where only one of several conditions needs to be met? If so, this article will be the key to significantly reducing your debugging time! 🔑

❌ Common Misconception: “Istio only uses OR conditions?”

To put it simply, no! Istio flexibly uses both AND and OR logic to enable powerful and granular traffic control. If you don’t understand how these two logics work, you’re likely to encounter unexpected results when creating complex routing rules.

---

🔗 AND Logic: Satisfy all conditions! (A single match block)

First, let’s look at AND logic. In Istio, when you define a single match block within an http routing rule and specify multiple fields (e.g., uri, method, headers) together within it, these fields are grouped with an AND condition.

This means that the incoming request must satisfy all conditions simultaneously within the match block for the routing rule to apply.

Example Scenario: Suppose you want to send only GET requests to the /api/v1/products path, where the user-group header is beta-testers, to the product-v2 service.

In this case, you can write the VirtualService as follows:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: product-reviews
spec:
  hosts:
    - product.example.com
  http:
  - match:
    - uri:
        prefix: "/api/v1/products" # Condition 1
      method:
        exact: "GET" # Condition 2
      headers:
        user-group:
          exact: "beta-testers" # Condition 3
    route:
    - destination:
        host: product-v2
        subset: v2

In the YAML file above, the three conditions within the match block are connected by AND.

1. The request URI starts with /api/v1/products AND
2. The HTTP method is exactly GET AND
3. The user-group header value is beta-testers

Only requests that satisfy all three of these conditions will be routed to the product-v2 service. If even one is not met, this rule is ignored.

---

🔀 OR Logic: Satisfy at least one! (Multiple match blocks)

So when do we use OR logic? It’s when you list multiple match blocks as a list (array). Think of starting a new item with a – symbol in YAML.

When you define multiple match blocks under an http rule, Istio checks if the incoming request satisfies at least one of these blocks. If even one is satisfied, the corresponding routing rule is immediately applied.

Example Scenario: Suppose you want to send all requests coming to the /mobile-api path OR requests with a ‘device: mobile’ header to the mobile-gateway service.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: api-gateway
spec:
  hosts:
    - api.example.com
  http:
  - match:
    - uri: # First match block (Condition A)
        prefix: "/mobile-api"
    - headers: # Second match block (Condition B)
        device:
          exact: "mobile"
    route:
    - destination:
        host: mobile-gateway
        subset: v1

In this configuration, there are two match blocks listed.

1. If the request URI starts with /mobile-api
2. OR if the device header value is mobile

If the request matches either of these two cases, it will be routed to mobile-gateway.

---

💡 Seeing the Big Picture: Becoming an Expert with AND and OR Combinations

Now the truly powerful aspect emerges. Istio can combine these two logics to achieve very sophisticated traffic control.

Complex logic like (Condition A AND Condition B) OR (Condition C AND Condition D) can also be easily implemented.

Advanced Example Scenario:

• Case 1: An internal employee (with ‘internal-user: true’ header) sends a POST request to the /admin page
• OR
• Case 2: A beta tester (with ‘user-group: beta’ header) accesses the /new-feature page

If you want to send both of these cases to the admin-panel-v2 service, how would you do it? You combine them like this:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: admin-access-control
spec:
  hosts:
    - admin.example.com
  http:
  - match:
    - headers: # First match block (Case 1)
        internal-user:
          exact: "true"
      uri:
        prefix: "/admin"
      method:
        exact: "POST"
    - headers: # Second match block (Case 2)
        user-group:
          exact: "beta"
      uri:
        prefix: "/new-feature"
    route:
    - destination:
        host: admin-panel-v2
        subset: v2

This VirtualService operates as follows:

• First match block: Header, URI, and method conditions are grouped by AND to handle Case 1.
• Second match block: Header and URI conditions are grouped by AND to handle Case 2.
• Relationship between the two match blocks: These two blocks are connected by an OR relationship, so if an incoming request matches Case 1 OR Case 2, it will be routed to admin-panel-v2.

✅ Conclusion

Now, the operation of Istio’s traffic matching rules should be clear.

• AND 🔗: When using multiple conditions within a single match block. “All conditions must be met!”
• OR 🔀: When listing multiple match blocks. “Only one of several conditions needs to be met!”

Understanding this simple yet powerful principle is the first step towards precise and stable traffic management using Istio. Stop wasting time on unexpected routing errors, and master AND and OR logic to perfectly control your service mesh!