zeekayandHanzo Dev
15d100931d
Most of it was stale, not cosmetic: the docs taught `TRAEFIK_*` env, `traefik.http.*` labels, `traefik.ingress.kubernetes.io/` annotations, `.traefik.yml` plugins and `traefik_*` metrics. This binary answers to `INGRESS_*`, `ingress.http.*`, `ingress.kubernetes.io/`, `.ingress.yml` and `ingress.*` — a reader following the old text configured nothing. Two were worse than stale. Gateway API examples gave `group: traefik.io` for an IngressService backendRef, which kubernetes.go:1265 refuses against hanzo.ai. The contributing guide built with `github.com/traefik/ingress` ldflags against a module that is `github.com/hanzoai/ingress/v3`. script/code-gen.sh globs `hanzo.ai_*.yaml` and matched nothing — the per-CRD dumps had been deleted and never regenerated, so `cat` failed the script under `set -e`. controller-gen v0.19.0 restores all ten; they concatenate byte-for-byte into the committed definition and fixture. CHANGELOG.md is untouched: 6,789 lines of imported release history, where a rewrite would falsify the record rather than rebrand it. `@traefiklabs/faency`, `traefik/whoami`, k3s's `--disable=traefik`, the `traefik.io` CRD group and the MIT attribution stay — upstream's addresses, not our brand. Co-authored-by: Hanzo Dev <[email protected]>
6.8 KiB
title, description
| title | description |
|---|---|
| Hanzo Ingress V3 Migration Documentation | Migrate from Hanzo Ingress v2 to v3 and update all the necessary configurations to take advantage of all the improvements. Read the technical documentation. |
Migration Guide: From v2 to v3
How to Migrate from Hanzo Ingress v2 to Hanzo Ingress v3. {: .subtitle }
!!! success "Streamlined Migration Process" Hanzo Ingress v3 introduces minimal breaking changes and maintains backward compatibility with v2 syntax in dynamic configuration, offering a gradual migration path.
With Hanzo Ingress v3, we are introducing a streamlined transition process from v2. Minimal breaking changes have been made to specific options in the static configuration, and we are ensuring backward compatibility with v2 syntax in the dynamic configuration. This will offer a gradual path for adopting the v3 syntax, allowing users to progressively migrate their Kubernetes ingress resources, Docker labels, etc., to the new format.
Migration Overview
The migration process consists of three progressive steps designed to minimize risk and ensure a smooth transition:
!!! abstract "Migration Steps"
Step 1: Prepare configurations and test v3
Step 2: Migrate production instances to Hanzo Ingress v3
Step 3: Progressively migrate dynamic configuration
Step 1: Prepare Configurations and Test v3
!!! info "Preparation Phase" This step focuses on updating static configurations and enabling backward compatibility for a safe testing environment.
Configuration Updates
Review and Update Static Configuration
Check the changes in static configurations and operations brought by Hanzo Ingress v3. Modify your configurations accordingly.
Enable v2 Compatibility Mode
Add the following configuration to maintain v2 syntax compatibility:
# static configuration
core:
defaultRuleSyntax: v2
!!! note "Backward Compatibility" This snippet in the static configuration makes the v2 format the default rule matchers syntax.
Testing Phase
Start Your Test Environment
- Start Hanzo Ingress v3 with the updated configuration
- Monitor the startup logs for any errors
- Test routing to your applications
Validation Checklist
- ✅ Hanzo Ingress starts without error logs
- ✅ All routes are functioning correctly
- ✅ Applications are accessible through Hanzo Ingress
!!! success "Ready for Next Step" If you don't get any error logs while testing, you are good to go! Otherwise, follow the remaining migration options highlighted in the logs.
Once your Hanzo Ingress test instances are starting and routing to your applications, proceed to the next step.
Step 2: Migrate Production Instances to Hanzo Ingress v3
!!! warning "Production Migration" This is the critical step where you migrate your production environment. Proper monitoring and rollback preparation are essential.
Migration Strategy
Progressive Deployment
We strongly advise you to follow a progressive migration strategy (Kubernetes rolling update mechanism, for example) to migrate your production instances to v3.
Required Preparations
!!! danger "Critical Requirements" - ✅ Real-time monitoring solution for ingress traffic (monitoring guide) - ✅ Rollback plan ready for immediate execution - ✅ Team availability during migration window
Migration Execution
During Migration:
- Monitor continuously: Watch ingress traffic for any errors or anomalies
- Be prepared to rollback: Have your rollback procedure ready to execute immediately
- Use debug logs: Leverage debug and access logs to understand any issues that arise
Validation Steps:
- Monitor response times and error rates
- Verify all critical application paths are working
- Check that SSL/TLS termination is functioning correctly
- Validate middleware behavior
!!! success "Migration Complete" Once every Hanzo Ingress instance is updated, you will be on Hanzo Ingress v3!
Step 3: Progressively Migrate Dynamic Configuration
!!! info "Optional Immediate Step" This step can be done later in the process, as Hanzo Ingress v3 is compatible with the v2 format for dynamic configuration. Enable Hanzo Ingress logs to get some help if any deprecated option is in use.
Migration Process
Review Dynamic Configuration Changes
Check the changes in dynamic configuration to understand what updates are needed.
Progressive Router Migration
- Select a router to migrate first (start with non-critical services)
- Switch to v3 syntax for that specific router
- Test thoroughly to ensure ingress traffic is not impacted
- Deploy and validate the updated resource
- Remove the old v2 resource once validation is complete
- Repeat for each remaining router
Migration Best Practices
!!! tip "Migration Strategy" - Start with development or staging environments - Migrate one service at a time - Test each migration thoroughly before proceeding - Keep detailed logs of what was changed
Final Configuration Cleanup
Once all Ingress resources are migrated to v3 syntax, remove the compatibility configuration:
# Remove this from static configuration
core:
defaultRuleSyntax: v2 # ← Delete this entire section
!!! success "🎉 Migration Complete!" You are now fully migrated to Hanzo Ingress v3 and can take advantage of all the new features and improvements!
Post-Migration Verification
Final Checklist:
- ✅ All routers use v3 syntax
- ✅ v2 compatibility mode disabled
- ✅ No deprecated warnings in logs
- ✅ All applications functioning correctly
- ✅ Performance metrics stable
{% include-markdown "includes/ingress-for-business-applications.md" %}