feat: add IP-based canary traffic routing support IFRFE-0

[devin-ai-integration]

feat: add IP-based canary traffic routing support IFRFE-0

Summary

This PR implements IP-based canary traffic routing for Flagger's Istio integration, extending the existing webhook mechanism to support consistent hashing of client IPs for gradual canary traffic routing.

Key changes:

• Added IPRangeRouting configuration to CanarySpec with support for consistent hashing strategies
• Created IPRangeCalculator utility package for IP range calculation and hash generation
• Extended confirm-traffic-increase webhook to include IP range metadata in payload
• Modified IstioRouter to generate IP-based HTTPMatchRequest rules using X-Client-IP-Hash header
• Added comprehensive test coverage and example configuration

Architecture: Uses header-based approach where gateway/ingress injects X-Client-IP-Hash header with hashed client IP, then Flagger matches against calculated hash ranges for routing decisions.

Review & Testing Checklist for Human

🟡 Medium Risk - 4 items to verify:

• Header injection dependency: Verify your gateway/ingress can inject the X-Client-IP-Hash header. The implementation assumes this header exists but doesn't automatically configure it - this is a critical integration requirement.

• Backward compatibility: Test that existing canary deployments without IP routing continue to work normally. Run a standard weighted canary rollout to ensure no regressions.

• Webhook payload compatibility: Verify that external webhook consumers can handle the new IP range metadata fields in webhook payloads without breaking existing integrations.

• Routing rule priority: Test scenarios where IP routing, A/B testing, and session affinity overlap to ensure routing precedence is correct and predictable.

End-to-End Test Plan

1. Deploy the example config (artifacts/examples/istio-ip-routing.yaml)
2. Configure gateway to inject X-Client-IP-Hash: slot-X header based on client IP hash
3. Start canary deployment and verify traffic gradually shifts based on IP ranges
4. Monitor webhook calls receive IP range metadata
5. Test that same IP consistently routes to same destination

Notes

• Requested by: Yunpeng Han (@yunpeng-moego)
• Devin session: https://app.devin.ai/sessions/7ddbf5d2cbbf4eb281a34ed932f1e22d
• The design allows future extension to general request header matching by following the same pattern
• Some existing tests were failing on base branch (session_affinity, ServicePromotionWithWeightsOverflow) - these are pre-existing issues unrelated to this PR

[devin-ai-integration]

Original prompt from Yunpeng

1. 使用flagger的istio-canary分支
2. 检查项目代码目前flagger支持的动态流量规则是随机流量的百分比
3. 如果需要支持在Canary过程根据客户端Ip进行Canary流量的扩展，应该如何设计和实现？
4. 比如 按照ip把10%范围的ip给路由到Canary实例，后续再把10%范围的ip给路由到Canary实例
5. 后续能否扩展为参数，指定请求头和值范围，根据一致性hash或者slot方式，依次扩大条件


You only need to look in the following repo: MoeGolibrary/flagger

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring