Mermaid diagrams: remove the yellow fill, add missing tutorial diagrams

tutorials/bicep/tags-labels-taints/README.md

@@ -24,6 +24,7 @@ By default the user agent pool carries the `workload=batch` node label, the `ded
 [main.bicep](main.bicep) is a resource-group-scoped template that composes nine local Bicep modules (`deploy.sh` creates the `local-rg` resource group first):
 
 ```mermaid
+%%{init: {'themeVariables': {'clusterBkg': 'transparent', 'clusterBorder': '#8c8c8c'}}}%%
 graph TD
   LA[module logAnalytics] --> ACR[module containerRegistry]
   LA --> KV[module keyVault]

tutorials/ccm/scripts/README.md

@@ -10,6 +10,43 @@ Because the emulated load balancer has no real dataplane, the `EXTERNAL-IP` is a
 
 > **Running on LocalStack?** Install the [lstk CLI](https://docs.localstack.cloud/aws/developer-tools/running-localstack/lstk/) and run `lstk az start-interception` to route Azure CLI calls to the emulator. See [Run against LocalStack](../../../README.md#run-against-localstack) for the full setup.
 
+## Architecture
+
+The cloud controller manager turns Kubernetes `Service` objects into Azure load-balancer resources in the node resource group, and writes the assigned address back onto the Service:
+
+```mermaid
+%%{init: {'themeVariables': {'clusterBkg': 'transparent', 'clusterBorder': '#8c8c8c'}}}%%
+flowchart LR
+    subgraph aks["AKS cluster"]
+        subgraph kubesystem["kube-system"]
+            ccm["cloud-controller-manager"]
+            cnm["cloud-node-manager"]
+        end
+        subgraph appns["test namespace"]
+            svcpub["Service<br/>type LoadBalancer"]
+            svcint["Service<br/>internal annotation"]
+            backend["backend Deployment"]
+        end
+    end
+
+    subgraph noderg["node resource group MC_*"]
+        lb["kubernetes<br/>load balancer"]
+        lbint["kubernetes-internal<br/>load balancer"]
+        pip["public IP address"]
+        nsg["network security group"]
+    end
+
+    svcpub -.->|"watched by"| ccm
+    svcint -.->|"watched by"| ccm
+    ccm -->|"frontend, rule, backend pool"| lb
+    ccm -->|"private frontend"| lbint
+    ccm -->|"allocates"| pip
+    ccm -->|"Allow rule per loadBalancerSourceRanges"| nsg
+    ccm -->|"writes EXTERNAL-IP back"| svcpub
+    cnm -->|"labels and addresses nodes"| aks
+    lb -.->|"backend pool targets"| backend
+```
+
 ## Prerequisites
 
 - An AKS cluster reachable through `kubectl`, created by [scripts/01-user-assigned-managed-identity.sh](../../../scripts/01-user-assigned-managed-identity.sh). The scripts do not create the cluster; they source `./00-variables.sh`, whose values must match it (`local-aks-test` in resource group `local-rg`, location `ItalyNorth`).

tutorials/gateway-api/scripts/README.md

@@ -18,6 +18,41 @@ This tutorial enables the Managed Gateway API on an AKS cluster (or the [LocalSt
 
 The cluster-creation scripts already enable the Managed Gateway API at create time, so `01-enable-gateway-api.sh` is idempotent: on such a cluster it detects the installation and leaves it in place. It still runs cleanly on a cluster created without it, enabling it through the live `az aks update` path.
 
+## Architecture
+
+The Managed Gateway API add-on installs only the CRDs; NGINX Gateway Fabric is the implementation that claims the `GatewayClass` and serves the traffic:
+
+```mermaid
+%%{init: {'themeVariables': {'clusterBkg': 'transparent', 'clusterBorder': '#8c8c8c'}}}%%
+flowchart LR
+    client(["curl -H 'Host: echo.local'"])
+
+    subgraph aks["AKS cluster"]
+        crds["gateway.networking.k8s.io CRDs<br/>installed by the add-on"]
+        gwclass["GatewayClass nginx"]
+
+        subgraph ngfns["namespace nginx-gateway"]
+            controller["NGINX Gateway Fabric<br/>controller"]
+            dataplane["per-Gateway NGINX<br/>data-plane Service and pods"]
+        end
+
+        subgraph testns["namespace gateway-api-test"]
+            gw["Gateway<br/>HTTP listener for echo.local"]
+            route["HTTPRoute<br/>every path of echo.local"]
+            svc["echo-server<br/>ClusterIP Service"]
+            deploy["echo-server<br/>Deployment"]
+        end
+    end
+
+    crds -.->|"define"| gw
+    gwclass -.->|"claimed by"| controller
+    gw -.->|"provisions"| dataplane
+    route -.->|"attached to"| gw
+    client -->|"kubectl port-forward"| dataplane
+    dataplane -->|"routes per HTTPRoute"| svc
+    svc --> deploy
+```
+
 ## How it works
 
 Run the numbered scripts in order. Each one sources [00-variables.sh](00-variables.sh) and is idempotent, so it can be re-run safely.

tutorials/keda/event-hubs/README.md

@@ -13,6 +13,7 @@ This tutorial creates an Event Hubs namespace with one event hub, a dedicated co
 The producer and the consumer are two workloads in the same Kubernetes namespace inside the AKS cluster. The producer sends events to the event hub, the consumer reads them and records its progress as checkpoints in blob storage, and the KEDA add-on in `kube-system` compares the two to work out the lag that drives the scaling.
 
 ```mermaid
+%%{init: {'themeVariables': {'clusterBkg': 'transparent', 'clusterBorder': '#8c8c8c'}}}%%
 flowchart LR
     subgraph aks["Azure Kubernetes Service cluster"]
         subgraph kubesystem["kube-system: KEDA add-on"]

tutorials/keda/queue-storage/README.md

@@ -16,6 +16,7 @@ The KEDA scaler **and** both applications authenticate with the same shared user
 The producer and the consumer are two workloads in the same Kubernetes namespace inside the AKS cluster, both running as the federated `queue-app` service account. The producer fills the storage queue, the consumer drains it, and the KEDA add-on in `kube-system` reads the queue's depth to decide how many consumer replicas should exist. Every arrow that touches Azure is authenticated with workload identity.
 
 ```mermaid
+%%{init: {'themeVariables': {'clusterBkg': 'transparent', 'clusterBorder': '#8c8c8c'}}}%%
 flowchart LR
     subgraph aks["Azure Kubernetes Service cluster"]
         subgraph kubesystem["kube-system: KEDA add-on"]

tutorials/keda/service-bus/README.md

@@ -15,6 +15,7 @@ The producer and consumer applications themselves use the namespace connection s
 The producer and the consumer are two workloads in the same Kubernetes namespace inside the AKS cluster. The producer fills the Service Bus queue, the consumer drains it, and the KEDA add-on in `kube-system` reads the queue's depth to decide how many consumer replicas should exist.
 
 ```mermaid
+%%{init: {'themeVariables': {'clusterBkg': 'transparent', 'clusterBorder': '#8c8c8c'}}}%%
 flowchart LR
     subgraph aks["Azure Kubernetes Service cluster"]
         subgraph kubesystem["kube-system: KEDA add-on"]

tutorials/terraform/tags-labels-taints/README.md

@@ -25,6 +25,7 @@ By default the user agent pool carries the `workload=batch` node label, the `ded
 The root [main.tf](main.tf) composes seven local Terraform modules around a single resource group, then adds the cross-module role assignments and the Managed Gateway API installation that no single module can own:
 
 ```mermaid
+%%{init: {'themeVariables': {'clusterBkg': 'transparent', 'clusterBorder': '#8c8c8c'}}}%%
 graph TD
   RG[azurerm_resource_group] --> LA[module log_analytics]
   RG --> VNET[module virtual_network]