Skip to content

Commit 8d84dfc

Browse files
salonichf5salonichf5
committed
update diagrams based on reviews
1 parent 4c79c37 commit 8d84dfc

File tree

1 file changed

+88
-77
lines changed

1 file changed

+88
-77
lines changed

‎content/ngf/overview/gateway-architecture.md‎

Lines changed: 88 additions & 77 deletions
Original file line numberDiff line numberDiff line change
@@ -58,76 +58,78 @@ This figure depicts an example of NGINX Gateway Fabric exposing three web applic
5858
```mermaid
5959
graph LR
6060
%% Nodes and Relationships
61-
subgraph KubernetesCluster[Kubernetes Cluster]
62-
subgraph ApplicationsNamespaceA[Namespace: applications]
63-
subgraph DataplaneComponentsA[Dataplane Components]
64-
GatewayA[Gateway A<br>Listener: *.example.com]
65-
subgraph NGINXPodA[NGINX Pod]
66-
subgraph NGINXContainerA[NGINX Container]
67-
NGINXProcessA(NGINX)
68-
NGINXAgentA(NGINX Agent)
61+
subgraph KubernetesCluster["Kubernetes Cluster"]
62+
subgraph NamespaceNGF["Namespace: nginx-gateway"]
63+
NGFControlPlanePod["NGINX Gateway Fabric Control Plane Pod"]
64+
NGFControlPlanePod --> KubernetesAPI["Kubernetes API"]
65+
end
66+
subgraph ApplicationsNamespaceA["Namespace: applications"]
67+
subgraph DataplaneComponentsA["Dataplane Components"]
68+
GatewayA["Gateway A<br>Listener: *.example.com"]
69+
subgraph NGINXDataPlanePodA["NGINX Data Plane Pod"]
70+
subgraph NGINXContainerA["NGINX Container"]
71+
NGINXProcessA["NGINX Process"]
72+
NGINXAgentA["NGINX Agent"]
6973
end
7074
end
7175
end
72-
subgraph HTTPRouteAAndApplications[HTTPRoutes and Applications]
73-
HTTPRouteA[HTTPRoute A\nHost: a.example.com]
74-
HTTPRouteB[HTTPRoute B\nHost: b.example.com]
75-
ApplicationA[Application A<br>Pods: 2]
76-
ApplicationB[Application B<br>Pods: 1]
76+
subgraph HTTPRouteAAndApplications["HTTPRoutes and Applications"]
77+
HTTPRouteA["HTTPRoute A<br>Host: a.example.com"]
78+
HTTPRouteB["HTTPRoute B<br>Host: b.example.com"]
79+
ApplicationA["Application A<br>Pods: 2"]
80+
ApplicationB["Application B<br>Pods: 1"]
7781
end
7882
end
79-
subgraph ApplicationsNamespaceB[Namespace: applications-2]
80-
subgraph DataplaneComponentsB[Dataplane Components]
81-
GatewayB[Gateway B<br>Listener: *.other-example.com]
82-
subgraph NGINXPodB[NGINX Pod]
83-
subgraph NGINXContainerB[NGINX Container]
84-
NGINXProcessB(NGINX)
85-
NGINXAgentB(NGINX Agent)
83+
subgraph ApplicationsNamespaceB["Namespace: applications-2"]
84+
subgraph DataplaneComponentsB["Dataplane Components"]
85+
GatewayB["Gateway B<br>Listener: *.other-example.com"]
86+
subgraph NGINXDataPlanePodB["NGINX Data Plane Pod"]
87+
subgraph NGINXContainerB["NGINX Container"]
88+
NGINXProcessB["NGINX Process"]
89+
NGINXAgentB["NGINX Agent"]
8690
end
8791
end
8892
end
89-
subgraph HTTPRouteBandApplications[HTTPRoutes and Applications]
90-
HTTPRouteC[HTTPRoute C\nHost: c.other-example.com]
91-
ApplicationC[Application C<br>Pods: 1]
93+
subgraph HTTPRouteBandApplications["HTTPRoutes and Applications"]
94+
HTTPRouteC["HTTPRoute C<br>Host: c.other-example.com"]
95+
ApplicationC["Application C<br>Pods: 1"]
9296
end
9397
end
94-
KubernetesAPI[Kubernetes API]
9598
end
96-
subgraph UsersAndClients[Users and Clients]
97-
UserOperator[Cluster Operator]
98-
UserDevA[Application Developer A]
99-
UserDevB[Application Developer B]
100-
ClientA[Client A]
101-
ClientB[Client B]
99+
subgraph UsersAndClients["Users and Clients"]
100+
UserOperator["Cluster Operator"]
101+
UserDevA["Application Developer A"]
102+
UserDevB["Application Developer B"]
103+
ClientA["Client A"]
104+
ClientB["Client B"]
102105
end
103-
subgraph SharedInfrastructure[Public Endpoint]
104-
PublicEndpoint[TCP Load Balancer / NodePort]
106+
subgraph SharedInfrastructure["Public Endpoint"]
107+
PublicEndpoint["TCP Load Balancer / NodePort"]
105108
end
106109
%% Updated Traffic Flow
107-
ClientA == a.example.com ==> PublicEndpoint
108-
ClientB == c.other-example.com ==> PublicEndpoint
109-
PublicEndpoint ==> NGINXProcessA
110-
PublicEndpoint ==> NGINXProcessB
111-
NGINXProcessA ==> ApplicationA
112-
NGINXProcessA ==> ApplicationB
113-
NGINXProcessB ==> ApplicationC
110+
ClientA-->|a.example.com|PublicEndpoint
111+
ClientB-->|c.other-example.com|PublicEndpoint
112+
PublicEndpoint==>NGINXProcessA
113+
PublicEndpoint==>NGINXProcessB
114+
NGINXProcessA==>ApplicationA
115+
NGINXProcessA==>ApplicationB
116+
NGINXProcessB==>ApplicationC
114117
%% Kubernetes Configuration Flow
115-
HTTPRouteA --> GatewayA
116-
HTTPRouteB --> GatewayA
117-
HTTPRouteC --> GatewayB
118-
UserOperator --> KubernetesAPI
119-
NGFPod[NGF Pod] --> KubernetesAPI
120-
NGFPod --gRPC--> NGINXAgentA
121-
NGFPod --gRPC--> NGINXAgentB
122-
NGINXAgentA --> NGINXProcessA
123-
NGINXAgentB --> NGINXProcessB
124-
UserDevA --> KubernetesAPI
125-
UserDevB --> KubernetesAPI
118+
HTTPRouteA-->GatewayA
119+
HTTPRouteB-->GatewayA
120+
HTTPRouteC-->GatewayB
121+
UserOperator-->KubernetesAPI
122+
NGFControlPlanePod--gRPC-->NGINXAgentA
123+
NGFControlPlanePod--gRPC-->NGINXAgentB
124+
NGINXAgentA-->NGINXProcessA
125+
NGINXAgentB-->NGINXProcessB
126+
UserDevA-->KubernetesAPI
127+
UserDevB-->KubernetesAPI
126128
%% Styling
127129
style UserOperator fill:#66CDAA,stroke:#333,stroke-width:2px
128130
style GatewayA fill:#66CDAA,stroke:#333,stroke-width:2px
129131
style GatewayB fill:#66CDAA,stroke:#333,stroke-width:2px
130-
style NGFPod fill:#66CDAA,stroke:#333,stroke-width:2px
132+
style NGFControlPlanePod fill:#66CDAA,stroke:#333,stroke-width:2px
131133
style NGINXProcessA fill:#66CDAA,stroke:#333,stroke-width:2px
132134
style NGINXProcessB fill:#66CDAA,stroke:#333,stroke-width:2px
133135
style KubernetesAPI fill:#9370DB,stroke:#333,stroke-width:2px
@@ -154,18 +156,18 @@ The figure shows:
154156

155157
| **Category** | **Description** |
156158
|-------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------|
157-
| **Namespaces** | - _Namespace: applications_: Contains Gateway A for `*.example.com`, handling Application A and Application B.<br>- _Namespace: applications-2_: Contains Gateway B for `*.other-example.com`, handling Application C. |
158-
| **Users** | - _Cluster Operator_: Sets up NGF and manages Gateway API resources by provisioning Gateways (A and B) and the NGF Pod.<br>- _Developers A & B_: Developers deploy their applications and create HTTPRoutes. |
159+
| **Namespaces** | - _Namespace: nginx-gateway_: Contains the NGINX Gateway Fabric Control Plane Pod, responsible for managing Gateway API configurations and provisioning NGINX Data Plane Pods.<br>- _Namespace: applications_: Contains Gateway A for `*.example.com`, handling Application A and Application B.<br>- _Namespace: applications-2_: Contains Gateway B for `*.other-example.com`, handling Application C. |
160+
| **Users** | - _Cluster Operator_: Sets up the NGINX Gateway Fabric Control Plane Pod and manages Gateway API resources by provisioning Gateways (A and B).<br>- _Developers A & B_: Developers deploy their applications and create HTTPRoutes associated with their Gateways. |
159161
| **Clients** | - _Client A_: Interacts with Application A through `a.example.com`.<br>- _Client B_: Interacts with Application C through `c.other-example.com`. |
160-
| **NGF Pod** | The control plane component, deployed in `nginx-gateway`, communicates with the Kubernetes API to:<br>- Fetch Gateway API resources.<br>- Dynamically manage NGINX data plane deployments. |
161-
| **Gateways** | - _Gateway A_: Listens for requests under `*.example.com`. Routes:<br>&nbsp;&nbsp;&nbsp;• _HTTPRoute A_: Routes `a.example.com` to Application A.<br>&nbsp;&nbsp;&nbsp;• _HTTPRoute B_: Routes `b.example.com` to Application B.<br>- _Gateway B_: Listens for requests under `*.other-example.com`. Routes:<br>&nbsp;&nbsp;&nbsp;• _HTTPRoute C_: Routes `c.other-example.com` to Application C. |
162-
| **Applications** | - _Application A_: Deployed by Developer A (2 pods) and routed to by Gateway A.<br>- _Application B_: Deployed by Developer A (1 pod) and routed to by Gateway A.<br>- _Application C_: Deployed by Developer B (1 pod) and routed to by Gateway B. |
163-
| **NGINX Pods** | - _NGINX Pod A_: Handles traffic from Gateway A:<br>&nbsp;&nbsp;&nbsp;• _NGINX Process A_: Routes to Application A and Application B.<br>&nbsp;&nbsp;&nbsp;• _NGINX Agent A_: Updates configuration via gRPC.<br>- _NGINX Pod B_: Handles traffic from Gateway B:<br>&nbsp;&nbsp;&nbsp;• _NGINX Process B_: Routes to Application C.<br>&nbsp;&nbsp;&nbsp;• _NGINX Agent B_: Updates configuration via gRPC. |
164-
| **Traffic Flow** | - _Client A_:<br>&nbsp;&nbsp;&nbsp;1. Sends requests to `a.example.com` via Public Endpoint.<br>&nbsp;&nbsp;&nbsp;2. Routed to Application A by NGINX Process A.<br>- _Client B_:<br>&nbsp;&nbsp;&nbsp;1. Sends requests to `c.other-example.com` via Public Endpoint.<br>&nbsp;&nbsp;&nbsp;2. Routed to Application C by NGINX Process B. |
165-
| **Public Endpoint** | A shared entry point (TCP Load Balancer or NodePort) that exposes the NGINX Service externally and forwards client traffic into the cluster. |
166-
| **Kubernetes API** | Acts as the central hub for resource management:<br>- Fetches Gateway API resources.<br>- Updates NGINX configuration dynamically via the NGF Pod. |
162+
| **NGINX Gateway Fabric Control Plane Pod** | The control plane pod, deployed in the `nginx-gateway` namespace, communicates with the Kubernetes API to:<br>- Fetch Gateway API resources.<br>- Dynamically provision and configure NGINX Data Plane Pods.<br>- Deliver traffic routing and configuration updates to NGINX Agent instances over gRPC. |
163+
| **Gateways** | - _Gateway A_: Listens for requests under `*.example.com`. Routes:<br>&nbsp;&nbsp;&nbsp;• _HTTPRoute A_: Routes requests to `a.example.com` into Application A.<br>&nbsp;&nbsp;&nbsp;• _HTTPRoute B_: Routes requests to `b.example.com` into Application B.<br>- _Gateway B_: Listens for requests under `*.other-example.com`. Routes:<br>&nbsp;&nbsp;&nbsp;• _HTTPRoute C_: Routes requests to `c.other-example.com` into Application C. |
164+
| **Applications** | - _Application A_: Deployed by Developer A (2 pods), routed by Gateway A via HTTPRoute A.<br>- _Application B_: Deployed by Developer A (1 pod), routed by Gateway A via HTTPRoute B.<br>- _Application C_: Deployed by Developer B (1 pod), routed by Gateway B via HTTPRoute C. |
165+
| **NGINX Data Plane Pods** | - _NGINX Data Plane Pod A_: Handles traffic routed from Gateway A:<br>&nbsp;&nbsp;&nbsp;• _NGINX Process A_: Forwards requests to Application A and Application B as defined in Gateway A's HTTPRoutes.<br>&nbsp;&nbsp;&nbsp;• _NGINX Agent A_: Receives configuration updates from the NGINX Gateway Fabric Control Plane Pod via gRPC.<br>- _NGINX Data Plane Pod B_: Manages traffic routed from Gateway B:<br>&nbsp;&nbsp;&nbsp;• _NGINX Process B_: Forwards requests to Application C as defined in Gateway B’s HTTPRoute.<br>&nbsp;&nbsp;&nbsp;• _NGINX Agent B_: Receives configuration updates via gRPC from the NGINX Gateway Fabric Control Plane Pod. |
166+
| **Traffic Flow** | - _Client A_:<br>&nbsp;&nbsp;&nbsp;1. Sends requests to `a.example.com` via the Public Endpoint.<br>&nbsp;&nbsp;&nbsp;2. Requests are routed by Gateway A and processed by NGINX Process A.<br>&nbsp;&nbsp;&nbsp;3. Traffic is forwarded to Application A.<br>- _Client B_:<br>&nbsp;&nbsp;&nbsp;1. Sends requests to `c.other-example.com` via the Public Endpoint.<br>&nbsp;&nbsp;&nbsp;2. Requests are routed by Gateway B and processed by NGINX Process B.<br>&nbsp;&nbsp;&nbsp;3. Traffic is forwarded to Application C. |
167+
| **Public Endpoint** | A shared entry point (TCP Load Balancer or NodePort) that exposes the NGINX Data Plane externally to forward client traffic into the cluster. |
168+
| **Kubernetes API** | Acts as the central hub for resource management:<br>- Fetches Gateway API resources for Gateway A and Gateway B.<br>- Facilitates NGINX configuration updates via the NGINX Gateway Fabric Control Plane Pod. |
167169

168-
{{% /bootstrap-table %}}
170+
{{< /bootstrap-table >}}
169171

170172

171173
_Color Coding_ :
@@ -180,14 +182,20 @@ _Color Coding_ :
180182
```mermaid
181183
graph LR
182184
%% Main Components
183-
KubernetesAPI[Kubernetes API]
185+
subgraph nginx-gateway["Namespace: nginx-gateway"]
186+
NGFPod[NGINX Gateway Fabric Control Plane Pod]
187+
end
188+
189+
subgraph NGINXDataPlane["NGINX Data Plane Pod"]
190+
NGINXAgent[NGINX Agent]
191+
NGINXMaster[NGINX Master]
192+
NGINXWorker[NGINX Worker]
193+
ConfigFiles[Config Files]
194+
end
195+
184196
F5Telemetry[F5 Telemetry Service]
185197
PrometheusMonitor[Prometheus]
186-
NGFPod[NGF Pod]
187-
NGINXAgent[NGINX Agent]
188-
NGINXMaster[NGINX Master]
189-
NGINXWorker[NGINX Worker]
190-
ConfigFiles[Config Files]
198+
KubernetesAPI[Kubernetes API]
191199
Client[Client]
192200
BackendApplication[Backend Application]
193201
@@ -220,20 +228,23 @@ graph LR
220228
The following table describes the connections, preceeded by their types in parentheses. For brevity, the suffix "process" has been omitted from the process descriptions.
221229

222230
{{< bootstrap-table "table table-bordered table-striped table-responsive" >}}
231+
223232
| # | Component/Protocol | Description |
224233
| ---| ----------------------- | ------------------------------------------------------------------------------------------------------------ |
225-
| 1 | Kubernetes API (HTTPS) | _Kubernetes API → NGF Pod_: The NGF Pod watches the Kubernetes API for Gateway API resources (e.g., Gateways, HTTPRoutes) to fetch the latest cluster configuration. |
226-
| 2 | gRPC | _NGF Pod → NGINX Agent_: The NGF Pod processes the Gateway API resources, generates NGINX configuration metadata, and sends it securely to the NGINX Agent over gRPC. |
227-
| 3 | File I/O | _NGINX Agent → Config Files_: The NGINX Agent validates the configuration and writes the configuration files. |
228-
| 4 | Signal | _NGINX Agent → NGINX Master_: The NGINX Agent signals the NGINX Master process to reload the updated configuration. This ensures the updated routes and settings are live. |
229-
| 5 | HTTP/HTTPS | _Prometheus → NGINX Worker_: Prometheus collects runtime metrics (e.g., traffic stats, request details) directly from the NGINX Worker via the HTTP endpoint (`:9113/metrics`). This data helps monitor the operational state of the data plane. |
230-
| 6 | HTTPS | _NGF Pod → F5 Telemetry Service_: The NGF Pod sends system and usage telemetry data (like API requests handled, error rates, and performance metrics) to the F5 Telemetry Service for analytics. |
231-
| 7 | HTTP, HTTPS | _Client → NGINX Worker_: Clients send traffic (e.g., HTTP/HTTPS requests) to the NGINX Worker. These are typically routed via a public LoadBalancer or NodePort to expose NGINX. |
232-
{{% /bootstrap-table %}}
234+
| 1 | Kubernetes API (HTTPS) | _Kubernetes API → NGINX Gateway Fabric Control Plane Pod_: The NGINX Gateway Fabric Control Plane Pod (in the `nginx-gateway` namespace) watches the Kubernetes API for updates to Gateway API resources (e.g., Gateways, HTTPRoutes), fetching the latest configuration to manage routing and traffic control. |
235+
| 2 | gRPC | _NGINX Gateway Fabric Control Plane Pod → NGINX Agent_: The NGINX Gateway Fabric Control Plane Pod processes Gateway API resources, generates NGINX configuration settings, and securely delivers them to the NGINX Agent inside the NGINX Data Plane Pod via gRPC. |
236+
| 3 | File I/O | _NGINX Agent → Config Files_: The NGINX Agent (within the NGINX Data Plane Pod) validates the configuration metadata received from the Control Plane Pod and writes it to NGINX configuration files within the pod. These files store dynamic routing rules and traffic settings. |
237+
| 4 | Signal | _NGINX Agent → NGINX Master_: After writing the configuration files, the NGINX Agent signals the NGINX Master process to reload the configuration. This ensures the NGINX Data Plane Pod immediately applies the updated routes and settings. |
238+
| 5 | HTTP/HTTPS | _Prometheus → NGINX Worker_: Prometheus collects runtime metrics (e.g., traffic statistics, request rates, and active connections) from the NGINX Worker process, which is part of the NGINX Data Plane Pod. The `/metrics` endpoint exposes these metrics for monitoring and observability. |
239+
| 6 | HTTPS | _NGINX Gateway Fabric Control Plane Pod → F5 Telemetry Service_: The NGINX Gateway Fabric Control Plane Pod sends telemetry data (e.g., API requests handled, usage metrics, performance stats, error rates) to the external F5 Telemetry Service for centralized monitoring and diagnostics. |
240+
| 7 | HTTP/HTTPS | _Client → NGINX Worker_: Clients send incoming application traffic (e.g., HTTP/HTTPS requests) to the NGINX Worker process within the NGINX Data Plane Pod. These requests are typically routed through a shared Public Endpoint (e.g., LoadBalancer or NodePort) before reaching the NGINX Data Plane. |
241+
| 8 | HTTP/HTTPS | _NGINX Worker → Backend Application_: The NGINX Worker process forwards client traffic to the appropriate backend application services (e.g., Pods) as defined in the routing rules and configuration received from the Control Plane Pod. |
242+
243+
{{< /bootstrap-table >}}
233244

234245
---
235246

236-
### NGINX Plus Features and Benefits
247+
### Additional features and enhancements when using NGINX Plus
237248

238249
NGINX Gateway Fabric supports both NGINX Open Source and NGINX Plus. While the previous diagram shows NGINX Open Source, using NGINX Plus provides additional capabilities, including:
239250

@@ -248,7 +259,7 @@ These features enable reduced downtime, improved performance during scaling even
248259

249260
### Resilience and fault isolation
250261

251-
This architecture separates the control plane and data plane, creating clear operational boundaries that improve resilience and fault isolation. It also enhances scalability, security, and reliability while reducing the risk of failures affecting both components.
262+
This architecture separates the control plane and data plane, creating clear operational boundaries that improve resilience and fault isolation:
252263

253264
#### Control plane resilience
254265

0 commit comments

Comments
 (0)