feat: Convert Mermaid diagrams to inline style (#987)

Author: shaun-nx

content/ngf/traffic-management/advanced-routing.md

@@ -15,7 +15,43 @@ In this guide we will configure advanced routing rules for multiple applications
 
 The following image shows the traffic flow that we will be creating with these rules.
 
-{{< img src="/ngf/img/advanced-routing.png" alt="" >}}
+```mermaid
+graph LR
+    users[Users]
+    ngfSvc["Public Endpoint<br>for<br>cafe.example.com"]
+    subgraph cluster [Kubernetes Cluster]
+        subgraph appNs [Namespace<br>default]
+            subgraph nsPadding [" "]
+                nginxPod[Pod<br>NGINX]
+                coffeeV1Pod[Pod<br>coffee v1]
+                coffeeV2Pod[Pod<br>coffee v2]
+                teaPod[Pod<br>tea]
+                teaPostPod[Pod<br>tea-post]
+            end
+        end
+    end
+
+  ngfSvc --> nginxPod
+  nginxPod --/coffee--> coffeeV1Pod
+  nginxPod --/coffee<br>header: version=v2<br>OR<br>/coffee?TEST=v2--> coffeeV2Pod
+  nginxPod --GET /tea--> teaPod
+  nginxPod --POST /tea--> teaPostPod
+  users --> ngfSvc
+
+  class clusterPadding,nsPadding,clusterPadding2 noBorder
+  class gwNS,appNs namespace
+  class ngfSvc,nginxPod nginxNode
+  class coffeeV1Pod,coffeeV2Pod coffeeNode
+  class teaPod,teaPostPod teaNode
+
+  classDef noBorder stroke:none,fill:none
+  classDef default fill:#FFFFFF,stroke:#000000
+  classDef namespace fill:#FFFFFF,stroke:#036ffc,stroke-dasharray: 5 5,text-align:center
+  classDef nginxNode fill:#b4e0ad,stroke:#2AA317
+  classDef coffeeNode fill:#edbd8c,stroke:#D9822B
+  classDef teaNode fill:#ff8f6a,stroke:#e5805f
+
+```
 
 The goal is to create a set of rules that will result in client requests being sent to specific backends based on the request attributes. In this diagram, we have two versions of the `coffee` service. Traffic for v1 needs to be directed to the old application, while traffic for v2 needs to be directed towards the new application. We also have two `tea` services, one that handles GET operations and one that handles POST operations. Both the `tea` and `coffee` applications share the same Gateway.
 

content/ngf/traffic-management/basic-routing.md

@@ -21,7 +21,21 @@ You can route traffic to your Kubernetes applications using the Gateway API and
 
 The application we are going to use in this guide is a simple **coffee** application comprised of one service and two pods:
 
-{{<img src="ngf/img/route-all-traffic-app.png" alt="This image shows a single 'coffee' Service connecting to two 'coffee' Pods.">}}
+```mermaid
+graph TB
+  subgraph cluster [Kubernetes Cluster]
+    style cluster fill:#FFFFFF,stroke:#000000
+    svc[Service<br>coffee]
+    pod1[Pod<br>coffee]
+    pod2[Pod<br>coffee]
+  end
+
+  svc --> pod1 & pod2
+
+  class pod1,pod2,svc appNode
+  classDef appNode fill:#edbd8c,stroke:#D9822B
+
+```
 
 Using this architecture, the **coffee** application is not accessible outside the cluster. We want to expose this application on the hostname "cafe.example.com" so that clients outside the cluster can access it.
 
@@ -96,15 +110,91 @@ service/coffee       ClusterIP   198.51.100.1     <none>        80/TCP    77s
 
 To route traffic to the **coffee** application, we will create a Gateway and HTTPRoute. The following diagram shows the configuration we are creating in the next step:
 
-{{<img src="ngf/img/route-all-traffic-config.png" alt="">}}
+```mermaid
+graph LR
+    subgraph config [Namespace default]
+      subgraph padding [" "]
+          direction LR
+          style config fill:#FFFFFF,stroke:#000000
+          subgraph gw[Gateway cafe]
+              subgraph gwPadding [" "]
+                  gwContents[HTTP/80]
+              end
+          end
+          subgraph hr[HTTPRoute coffee]
+              subgraph hrPadding [" "]
+                  hrContents[cafe.example.com]
+                  subgraph describeMatchAll [Match all<br>traffic]
+                      subgraph describeMatchPadding [" "]
+                          matchAll[Host: *<br>Path: *]
+                      end
+                  end
+                  subgraph describeService [Group matching<br>pods within a Service]
+                      subgraph describePadding [" "]
+                          coffeeSvc[Service<br>coffee]
+                      end
+                  end
+              end
+          end
+      end
+    end
+
+  gwContents --> hrContents --> matchAll --> coffeeSvc
+  class padding,gwPadding,hrPadding,describeMatchAll,describeService,describePadding,describeMatchPadding noBorder
+  class gw gateway
+  class hr httpRoute
+  class matchAll,hrContents,coffeeSvc appDevNode
+  class gwContents clusterOppNode
+
+  classDef noBorder stroke:none,fill:none,text-align:center
+  classDef default fill:#FFFFFF,stroke:#000000
+  classDef gateway fill:#FFFFFF,stroke:#blue,stroke-dasharray: 3 3,text-align:center
+  classDef httpRoute fill:#FFFFFF,stroke:#D9822B,stroke-dasharray: 3 3,text-align:center
+  classDef appDevNode fill:#edbd8c,stroke:#D9822B
+  classDef clusterOppNode fill:lightblue,stroke:darkblue
+```
 
 We need a Gateway to create an entry point for HTTP traffic coming into the cluster. The **cafe** Gateway we are going to create will open an entry point to the cluster on port 80 for HTTP traffic.
 
 To route HTTP traffic from the Gateway to the **coffee** service, we need to create an HTTPRoute named **coffee** and attach it to the Gateway. This HTTPRoute will have a single routing rule that routes all traffic to the hostname "cafe.example.com" from the Gateway to the **coffee** service.
 
 Once NGINX Gateway Fabric processes the **cafe** Gateway and **coffee** HTTPRoute, it will configure a data plane (NGINX) to route all HTTP requests sent to "cafe.example.com" to the pods that the **coffee** service targets:
 
-{{<img src="ngf/img/route-all-traffic-flow.png" alt="Traffic Flow">}}
+```mermaid
+graph LR
+  style cluster fill:#FFFFFF,stroke:#000000
+  clients[Clients]
+  ngfSvc["Public IP Address for<br>cafe.example.com"]
+    subgraph cluster [Kubernetes Cluster]
+        
+        subgraph appNs [Namespace<br>default]
+            subgraph nsPadding [" "]
+            nginxPod[Pod NGINX]
+                coffeePod1[Pod coffee]
+                coffeePod2[Pod coffee]
+            end
+        end
+    end
+
+  ngfSvc --> nginxPod
+  nginxPod --> coffeePod1 & coffeePod2
+  clients --> ngfSvc
+
+  class clusterPadding,nsPadding,clusterPadding2 noBorder
+  class gwNS,appNs namespace
+  class nginxPod nginxNode
+  class coffeePod1,coffeePod2 coffeeNode
+  class ngfSvc svc
+  class clients clientNode
+
+  classDef noBorder stroke:none,fill:none
+  classDef default fill:#FFFFFF,stroke:#000000
+  classDef namespace fill:#FFFFFF,stroke:#036ffc,stroke-dasharray: 5 5,text-align:center
+  classDef nginxNode fill:#b4e0ad,stroke:#2AA317
+  classDef svc fill:lightblue,stroke:darkblue
+  classDef coffeeNode fill:#edbd8c,stroke:#D9822B
+  classDef clientNode fill:#D3D3D3
+```
 
 The **coffee** service is omitted from the diagram above because the NGINX Pod routes directly to the pods that the **coffee** service targets.