updating several diagrams for clarity

content/en/docs/concepts/architecture/_index.md

@@ -15,10 +15,16 @@ usually runs multiple nodes, providing fault-tolerance and high availability.
 
 This document outlines the various components you need to have for a complete and working Kubernetes cluster.
 
-{{< figure src="/images/docs/kubernetes-cluster-architecture.svg" alt="The control plane (kube-apiserver, etcd, kube-controller-manager, kube-scheduler) and several nodes. Each node is running a kubelet and kube-proxy." caption="Figure 1. Kubernetes cluster components." class="diagram-large" >}}
+{{< figure
+   src="/images/docs/components-of-kubernetes.svg"
+   alt="Diagram showing Kubernetes control plane components (API server, etcd, controller manager, and scheduler) and worker nodes each running kubelet and kube-proxy."
+   caption="Figure – Kubernetes cluster components, showing control plane services and node components."
+   class="diagram-large"
+>}}
+
 
 {{< details summary="About this architecture" >}}
-The diagram in Figure 1 presents an example reference architecture for a Kubernetes cluster.
+The diagram in the figure above presents an example reference architecture for a Kubernetes cluster.
 The actual distribution of components can vary based on specific cluster setups and requirements.
 
 In the diagram, each node runs the [`kube-proxy`](#kube-proxy) component. You need a

content/en/docs/concepts/cluster-administration/node-autoscaling.md

@@ -132,22 +132,13 @@ consolidate Nodes. This means that they need to be explicitly integrated with ea
 provider. The performance and feature set of a given autoscaler can differ between cloud provider
 integrations.
 
-{{< mermaid >}}
-graph TD
-    na[Node autoscaler]
-    k8s[Kubernetes]
-    cp[Cloud Provider]
-
-    k8s --> |get Pods/Nodes|na
-    na --> |drain Nodes|k8s
-    na --> |create/remove resources backing Nodes|cp
-    cp --> |get resources backing Nodes|na
-
-    classDef white_on_blue fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
-    classDef blue_on_white fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
-    class na blue_on_white;
-    class k8s,cp white_on_blue;
-{{</ mermaid >}}
+{{< figure
+   src="/images/docs/k8s-docs-autoscalers.svg"
+   alt="Diagram showing how the Kubernetes Node Autoscaler interacts with Kubernetes and the Cloud Provider. The autoscaler gets Pod and Node information from Kubernetes, requests new resources or deletes existing ones from the Cloud Provider, and drains nodes when scaling down."
+   caption="Figure – How the Kubernetes Node Autoscaler coordinates with the cluster and cloud provider to add or remove nodes based on workload demand."
+   class="diagram-large"
+>}}
+
 
 ### Autoscaler implementations
 

content/en/docs/concepts/security/controlling-access.md

@@ -18,7 +18,14 @@ authorized for API access.
 When a request reaches the API, it goes through several stages, illustrated in the
 following diagram:
 
-![Diagram of request handling steps for Kubernetes API request](/images/docs/admin/access-control-overview.svg)
+{{< figure
+   src="/images/docs/controlling-access-to-k8s-api.svg"
+   alt="Diagram showing how the Kubernetes API server processes requests. A user or service account sends a request that passes through authentication, authorization, and admission control before being persisted in etcd."
+   caption="Figure – How the Kubernetes API server authenticates, authorizes, and validates requests before storing them in etcd."
+   class="diagram-large"
+>}}
+
+
 
 ## Transport security
 

content/en/docs/concepts/services-networking/ingress.md

@@ -51,7 +51,13 @@ Traffic routing is controlled by rules defined on the Ingress resource.
 
 Here is a simple example where an Ingress sends all its traffic to one Service:
 
-{{< figure src="/docs/images/ingress.svg" alt="ingress-diagram" class="diagram-large" caption="Figure. Ingress" link="https://mermaid.live/edit#pako:eNqNkstuwyAQRX8F4U0r2VHqPlSRKqt0UamLqlnaWWAYJygYLB59KMm_Fxcix-qmGwbuXA7DwAEzzQETXKutof0Ovb4vaoUQkwKUu6pi3FwXM_QSHGBt0VFFt8DRU2OWSGrKUUMlVQwMmhVLEV1Vcm9-aUksiuXRaO_CEhkv4WjBfAgG1TrGaLa-iaUw6a0DcwGI-WgOsF7zm-pN881fvRx1UDzeiFq7ghb1kgqFWiElyTjnuXVG74FkbdumefEpuNuRu_4rZ1pqQ7L5fL6YQPaPNiFuywcG9_-ihNyUkm6YSONWkjVNM8WUIyaeOJLO3clTB_KhL8NQDmVe-OJjxgZM5FhFiiFTK5zjDkxHBQ9_4zB4a-x20EGNSZhyaKmXrg7f5hSsvufUwTMXThtMWiot5Jh6p9ffimHijIezaSVoeN0uiqcfMJvf7w" >}}
+{{< figure
+   src="/images/docs/ingress.svg"
+   alt="Diagram showing how an Ingress-managed load balancer routes external client traffic through an Ingress resource to a Kubernetes Service, which then forwards requests to backend Pods."
+   caption="Figure – How Ingress routes external traffic to services and pods within a Kubernetes cluster."
+   class="diagram-large"
+>}}
+
 
 An Ingress may be configured to give Services externally-reachable URLs,
 load balance traffic, terminate SSL / TLS, and offer name-based virtual hosting.
@@ -419,7 +425,13 @@ A fanout configuration routes traffic from a single IP address to more than one
 based on the HTTP URI being requested. An Ingress allows you to keep the number of load balancers
 down to a minimum. For example, a setup like:
 
-{{< figure src="/docs/images/ingressFanOut.svg" alt="ingress-fanout-diagram" class="diagram-large" caption="Figure. Ingress Fan Out" link="https://mermaid.live/edit#pako:eNqNUslOwzAQ_RXLvYCUhMQpUFzUUzkgcUBwbHpw4klr4diR7bCo8O8k2FFbFomLPZq3jP00O1xpDpjijWHtFt09zAuFUCUFKHey8vf6NE7QrdoYsDZumGIb4Oi6NAskNeOoZJKpCgxK4oXwrFVgRyi7nCVXWZKRPMlysv5yD6Q4Xryf1Vq_WzDPooJs9egLNDbolKTpT03JzKgh3zWEztJZ0Niu9L-qZGcdmAMfj4cxvWmreba613z9C0B-AMQD-V_AdA-A4j5QZu0SatRKJhSqhZR0wjmPrDP6CeikrutQxy-Cuy2dtq9RpaU2dJKm6fzI5Glmg0VOLio4_5dLjx27hFSC015KJ2VZHtuQvY2fuHcaE43G0MaCREOow_FV5cMxHZ5-oPX75UM5avuXhXuOI9yAaZjg_aLuBl6B3RYaKDDtSw4166QrcKE-emrXcubghgunDaY1kxYizDqnH99UhakzHYykpWD9hjS--fEJoIELqQ" >}}
+{{< figure
+   src="/images/docs/fan-out.svg"
+   alt="Diagram showing how an Ingress-managed load balancer routes client requests through a single Ingress resource to multiple services based on URL paths."
+   caption="Figure – Ingress fan-out pattern: a single Ingress resource routes client requests to multiple backend services based on URL paths."
+   class="diagram-large"
+>}}
+
 
 It would require an Ingress such as:
 
@@ -463,7 +475,13 @@ you are using, you may need to create a default-http-backend
 
 Name-based virtual hosts support routing HTTP traffic to multiple host names at the same IP address.
 
-{{< figure src="/docs/images/ingressNameBased.svg" alt="ingress-namebase-diagram" class="diagram-large" caption="Figure. Ingress Name Based Virtual hosting" link="https://mermaid.live/edit#pako:eNqNkl9PwyAUxb8KYS-atM1Kp05m9qSJJj4Y97jugcLtRqTQAPVPdN_dVlq3qUt8gZt7zvkBN7xjbgRgiteW1Rt0_zjLNUJcSdD-ZBn21WmcoDu9tuBcXDHN1iDQVWHnSBkmUMEU0xwsSuK5DK5l745QejFNLtMkJVmSZmT1Re9NcTz_uDXOU1QakxTMJtxUHw7ss-SQLhehQEODTsdH4l20Q-zFyc84-Y67pghv5apxHuweMuj9eS2_NiJdPhix-kMgvwQShOyYMNkJoEUYM3PuGkpUKyY1KqVSdCSEiJy35gnoqCzLvo5fpPAbOqlfI26UsXQ0Ho9nB5CnqesRGTnncPYvSqsdUvqp9KRdlI6KojjEkB0mnLgjDRONhqENBYm6oXbLV5V1y6S7-l42_LowlIN2uFm_twqOcAW2YlK0H_i9c-bYb6CCHNO2FFCyRvkc53rbWptaMA83QnpjMS2ZchBh1nizeNMcU28bGEzXkrV_pArN7Sc0rBTu" >}}
+{{< figure
+   src="/images/docs/k8s-docs-name-based-virtual-hosting.svg"
+   alt="Diagram showing an Ingress-managed load balancer routing client requests to different backend services based on hostnames such as foo.bar.com and bar.foo.com."
+   caption="Figure – Ingress name-based virtual hosting: a single Ingress resource routes traffic to different backend services based on the requested host name."
+   class="diagram-large"
+>}}
+
 
 The following Ingress tells the backing load balancer to route requests based on
 the [Host header](https://tools.ietf.org/html/rfc7230#section-5.4).

content/en/docs/concepts/workloads/pods/_index.md

@@ -424,7 +424,14 @@ acts as a web server for files in a shared volume, and a separate
 [sidecar container](/docs/concepts/workloads/pods/sidecar-containers/)
 that updates those files from a remote source, as in the following diagram:
 
-{{< figure src="/images/docs/pod.svg" alt="Pod creation diagram" class="diagram-medium" >}}
+{{< figure
+   src="/images/docs/multi-container-pod.svg"
+   alt="Diagram of a multi-container Pod in Kubernetes, showing multiple containers sharing the same network namespace and storage volumes."
+   caption="Figure – A multi-container Pod runs multiple tightly coupled containers that share networking and storage."
+   class="diagram-medium"
+>}}
+
+
 
 Some Pods have {{< glossary_tooltip text="init containers" term_id="init-container" >}}
 as well as {{< glossary_tooltip text="app containers" term_id="app-container" >}}.

content/en/docs/concepts/workloads/pods/sidecar-containers.md

@@ -47,6 +47,8 @@ Here's an example of a Deployment with two containers, one of which is a sidecar
 
 {{% code_sample language="yaml" file="application/deployment-sidecar.yaml" %}}
 
+{{< figure src="/images/docs/sidecar.svg" alt="Diagram showing the sidecar container pattern where a secondary container continuously reads logs from the main application container" caption="This reflects the sidecar pattern where the sidecar (logshipper) continuously tails logs written by the main container (myapp)." class="diagram-large" >}}
+
 ## Sidecar containers and Pod lifecycle
 
 If an init container is created with its `restartPolicy` set to `Always`, it will