With one replica, a Blazor Server island is an ordinary web server: the connection goes to the only process, the state lives in its memory, and a restart ends everything. With two replicas none of that holds anymore unless something is done about it. This lesson describes what the Kladde needs for that and gives the reason for every setting. It is just as clear about what was not run: Nothing in this lesson ran against Azure. What was compiled and what ran locally is in the box "Status of verification".
Where the Kladde stands
The lesson presupposes from K2 lessons 2.9.4 ("Azure before the first deploy") and 2.9.5 ("Deploying with azd"). K2 lesson 2.13.3 ("Scaling SignalR") prepared, in the section "Blazor Server and Container Apps", that from two replicas on the islands need session affinity and shared keys. Managed identity, Key Vault, Blob Storage, health probes and load tests are covered by K3 (lessons 3.3.1, 3.3.2, 3.6.3, 3.4.5 and 3.8.6); they are presupposed here. New is deploying the Kladde with two replicas: a Bicep description for the web app, the keys in Program.cs and the "Operations" section of the decision folder. The lesson "Choosing and justifying render modes" determined which pages are Server islands, "State: prerendering, persistence, reconnecting" determined what a dropped connection costs, and "Performance and size" supplies the calculation of memory per circuit.