[ExtraToast]

Part of #12: the warmup, triggered from the tend loop, which is the maintainer's choice. The Reporter's half, failing the Rollout on what this records, follows in its own pull request and closes #12.

Problem

After promotion nothing requests a release through the edge. The first visitor pays for the cold caches nearest the cluster, and an edge that cannot serve the new primary goes unnoticed until someone visits. Chapter 55 says the gate warms each release up through its public hostnames, and that a 5xx there fails the Rollout. Flagger asks the gate nothing after promotion, so no webhook can start it.

Change

• When. In the tend loop, the first round an Application serves a new revision, when every member's primary runs what its Deployment holds. A revision is warmed once and never again: a failure fails the Rollout and rolls nothing back.
• What. For each member, in name order: every path its Canary hands the gate (each Route path, then the readiness path), through each of the Canary's hostnames, the hosts of its anonymous and authenticated routes. The Canary reader now reads hostnames, and refuses a Canary whose webhooks disagree on them.
• How, per chapter 55's rules for a warmup and the security review on Release Gate: send test traffic to the Canary, and warm the public caches after promotion #12:
  • https on port 443 only, no proxy, no redirect followed;
  • the hostname resolved as an absolute name (host.), so the cluster's search path never completes it into a Service;
  • a connection only to a public address, decided on the address, not the name. Loopback, private (and so the cluster's pod and service ranges), link-local, multicast, the tailnet's 100.64.0.0/10 and the reserved blocks are refused;
  • IPv4 only, because the derived internet egress admits no IPv6 address.
• What fails it. A 5xx, or no answer within 10 seconds, stops the warmup at that request. A 401, a 404 or a redirect passes. A host or path that does not parse fails it without a request.
• What it records. The release record gains warmup: {revision, failed}, where failed names the first failing request. GET /releases serves it, which is how the Reporter will read it. An Application no public host reaches is recorded as warmed without a request.
• Its network. deploy/delivery.project.yml declares the Release Gate's internet egress, with its reason. deploy-kit validate accepts the file.
• README. The tend loop's section describes all of this.

To know

• One warmup per Application follows the first deploy of this version, since no record yet says a serving revision was warmed. Each is a handful of GETs through the edge.
• Policies are still render-only, so the egress declaration changes nothing live yet.

Checks

• New warmup_test.go:
  • the requests a new serving revision makes, in order, and that the next round makes none;
  • a 401/404/302 passing, and a 502 or no answer stopping the warmup with what it met;
  • no request for an Application with no public host, for a release still under way, or for a bad host or path;
  • GET /releases carrying the outcome;
  • the dialer: absolute-name lookup, only the public address dialed, port 80 refused, an all-internal name refused, lookup and dial errors returned;
  • the public-address table;
  • PublicTraffic refusing localhost and plain http.
• kube_test.go covers reading hostnames, and a Canary whose webhooks disagree on them.
• internal/gate passes in full, envtest included, at 98.0% coverage. golangci-lint reports 0 issues.