[ExtraToast]

Part of #12: the analysis half. The warmup after promotion follows in its own pull request.

Problem

Flagger switches blue-green with provider: kubernetes, so a new copy gets no user request before it is promoted. Its own request metrics hold only the kubelet's probes, and a static runtime exports none at all. The gate held each iteration to pod health alone, so a copy that answered every request with a 5xx, or slowly, was promoted.

Change

On each analysis iteration the gate now sends its own requests, as #12's decision and deploy-kit's chapter 55 ("A check sends its own traffic") say.

• What it requests. Every path the Canary's webhooks hand it, each once: every Route path, then the readiness path, three times over. It reads them, and the Canary service's port, off the Canary object in the cluster, as it reads everything else. A Canary whose webhooks disagree on the paths is not one the render wrote.
• Where. http://<process>-canary.<namespace>.svc.cluster.local:<port><path>. The gate builds the address itself; a project file supplies none of it.
• What fails. A 5xx, or no answer within 2 seconds. Anything else passes, a 401, a 404 and a 3xx included, and the gate never follows a redirect.
• What it is held to. The errorRate and latency in the release-gate inputs. The iteration fails when the failed share is over the error rate, when the p95 (nearest rank) of the answered requests is over the latency, or when nothing succeeded: no data is no.
• What it refuses to send. A path that is not URL path segments each opened by one / (a second /, a query, a fragment), or a Canary with no service port. Each is a question the gate cannot answer, so the answer is 503 and nothing is sent. The schema already guarantees the path's shape, but the gate holds API access, so it checks again.
• Order. Pods first: a new copy whose pods are not all ready is not requested. A member the Canary hands no path to is held to its pods alone, as before.
• Budget. At most 4 requests open at once and 8 seconds for the iteration, inside the 10 seconds Flagger waits on a webhook.

The README's Release Gate section records all of this, replacing "error-rate and latency are not measured yet".

To know

• Network policy. deploy-kit's rendered policies admit neither half of this traffic yet: the gate's egress allows only DNS and the API server. They are still render-only, so nothing blocks it today. deploy-kit#602 adds the rule before enforcement lands. On the live cluster, every leftover old-path policy in front of a gated member admits delivery-system.
• A connection that fails counts as no answer, the same as a timeout.

Checks

• New traffic_test.go:
  • every outcome above: quick, 401/404/302, one path 503, one path unanswered, nothing answered, one path slow, slow and failing, exactly at the bound;
  • the URLs asked: each distinct path three times, at the Canary service;
  • nothing sent for a member with no path, for pods not ready, for each refused path, for a missing or out-of-range port, and for thresholds that do not parse;
  • HTTPTraffic against a real server: it returns the 302 without requesting Location, reports a 500, and errors when the server is gone.
• TestACanaryIsReadWithWhatItsWebhooksCarryAndWhatFlaggerRecorded now covers the port, the paths and the readiness path, and two Canaries whose webhooks disagree on them.
• task test locally: internal/gate passes in full, envtest included, at 98.0% coverage. Only the Docker-backed vaultpolicy and catalog cases fail, because Docker isn't running here; CI runs them. golangci-lint reports 0 issues.