kcon2025/london: add diagrams (#18)

Diagrams by @mjudeikis

Co-authored-by: Mangirdas Judeikis <mangirdas@judeikis.lt>

Author: gman0

20250401-kubecon-london/workshop/02-explore-workspaces/README.md

@@ -307,6 +307,9 @@ default     buckaroo-bill
 default     hold-the-wall
 ```
 
+![Diagram of a LogicalCluster](./diagram-api-endpoint.png#only-light)
+![Diagram of a LogicalCluster](./diagram-api-endpoint-dark.png#only-dark)
+
 You can play around with inspecting the json output of those commands, and try addressing a specific cluster instead of all of them (wildcard `*`) to get some intuition about how they are wired together.
 
 From that, you can already start imagining what a workspace-aware controller operating on these objects would look like: being able to observe global state in its workspace subtree, it would watch spec updates from its children (Spec up), and push them status updates (Status down). Our basic example is lacking such a controller. But that's something we are going to fix the next exercise, on a more interesting example!

20250401-kubecon-london/workshop/02-explore-workspaces/diagram-api-endpoint-dark.png

@@ -296,6 +296,9 @@ kcp-superuser   kubernetes.io/basic-auth   2      9m3s
 
 Indeed, if you check the kcp side, you'll see that we have only one consumer `pg` with a single database instance in our workspace `root:consumers:pg`. Nothing stops us from creating more however. We are however going to limit ourselves to only one consumer during the workshop. Feel free to explore and create more consumers later yourself!
 
+![Diagram of a PGaaS with a single provider and two consumers](./pgaas.png#only-light)
+![Diagram of a PGaaS with a single provider and two consumers](./pgaas-dark.png#only-dark)
+
 Now, what can we do with it? You may recall that there were Secrets involved in the permission claims when we bound the APIExport. As it turns out, we have a Secret with admin access to the PostgreSQL server (as we should, we own it!), and can use it to authenticate.
 
 > A side note: we are going to cheat a bit now. We are running all the clusters on the same machine, and we know what IPs and ports to use. Having the username and the password to the DB is one thing, knowing where to connect is another. In the real world, **SQL<sup>3</sup> Co.** would have created a proper Ingress with a Service for us, and generated a connection string inside a Secret, and this would all work as it stands. Not having done that though, let's agree on a simplification: in place of ingress we will use port-forwarding, and the connection string we will create ourselves.

20250401-kubecon-london/workshop/02-explore-workspaces/diagram-api-endpoint.png

@@ -140,6 +140,9 @@ NAME                                             DESIRED   CURRENT   READY   AGE
 replicaset.apps/application-kcp--578c5dd4df      1         1         1       29s
 ```
 
+![Diagram of a multicluster Application deployment provider](./pgadminaas.png#only-light)
+![Diagram of a multicluster Application deployment provider](./pgadminaas-dark.png#only-dark)
+
 Continuing in our consumer workspace, let's check the Application object!
 
 ```shell-session