diff --git a/content/ngf/overview/gateway-architecture.md b/content/ngf/overview/gateway-architecture.md index 8cb041f4e..fda4959ef 100644 --- a/content/ngf/overview/gateway-architecture.md +++ b/content/ngf/overview/gateway-architecture.md @@ -24,87 +24,338 @@ NGINX Gateway Fabric is an open source project that provides an implementation o For a list of supported Gateway API resources and features, see the [Gateway API Compatibility]({{< ref "/ngf/overview/gateway-api-compatibility.md" >}}) documentation. +NGINX Gateway Fabric separates the control plane and data plane into distinct deployments. The control plane interacts with the Kubernetes API to watch for Gateway API resources. When a new Gateway resource is provisioned, the control plane dynamically creates and manages a corresponding NGINX data plane Deployment and Service. Each NGINX data plane pod consists of an NGINX container with the integrated [NGINX agent](https://github.com/nginx/agent), which securely communicates with the control plane over gRPC. The control plane translates Gateway API resources into NGINX configuration, and sends the configuration to the agent. This enables multiple Gateways to be managed centrally while ensuring that each NGINX instance remains aligned with the current cluster state. Labels, annotations, and infrastructure settings such as service type or replica count can be specified globally via the Helm chart or customized per Gateway using the enhanced NginxProxy CRD and the Gateway’s `infrastructure` section. + We have more information regarding our [design principles](https://github.com/nginx/nginx-gateway-fabric/blob/v1.6.1/docs/developer/design-principles.md) in the project's GitHub repository. --- -## NGINX Gateway Fabric at a high level +## NGINX Gateway Fabric Deployment Model and Architectural Overview -This figure depicts an example of NGINX Gateway Fabric exposing two web applications within a Kubernetes cluster to clients on the internet: +The NGINX Gateway Fabric architecture separates the control plane and data plane into distinct and independent Deployments, ensuring enhanced security, flexibility, and resilience. -{{< img src="/ngf/img/ngf-high-level.png" alt="" >}} +### Control Plane: Centralized Management -{{< note >}} The figure does not show many of the necessary Kubernetes resources the Cluster Operators and Application Developers need to create, like deployment and services. {{< /note >}} +The control plane operates as a Deployment, serving as a [Kubernetes controller](https://kubernetes.io/docs/concepts/architecture/controller/) built with the [controller-runtime](https://github.com/kubernetes-sigs/controller-runtime) library. It manages all aspects of resource provisioning and configuration for the NGINX data planes by watching Gateway API resources and other Kubernetes objects such as Services, Endpoints, and Secrets. -The figure shows: +Key functionalities include: -- A _Kubernetes cluster_. -- Users _Cluster Operator_, _Application Developer A_ and _Application Developer B_. These users interact with the cluster through the Kubernetes API by creating Kubernetes objects. -- _Clients A_ and _Clients B_ connect to _Applications A_ and _B_, respectively, which they have deployed. -- The _NGF Pod_, [deployed by _Cluster Operator_]({{< ref "/ngf/installation">}}) in the namespace _nginx-gateway_. For scalability and availability, you can have multiple replicas. This pod consists of two containers: `NGINX` and `NGF`. The _NGF_ container interacts with the Kubernetes API to retrieve the most up-to-date Gateway API resources created within the cluster. It then dynamically configures the _NGINX_ container based on these resources, ensuring proper alignment between the cluster state and the NGINX configuration. -- _Gateway AB_, created by _Cluster Operator_, requests a point where traffic can be translated to Services within the cluster. This Gateway includes a listener with a hostname `*.example.com`. Application Developers have the ability to attach their application's routes to this Gateway if their application's hostname matches `*.example.com`. -- _Application A_ with two pods deployed in the _applications_ namespace by _Application Developer A_. To expose the application to its clients (_Clients A_) via the host `a.example.com`, _Application Developer A_ creates _HTTPRoute A_ and attaches it to `Gateway AB`. -- _Application B_ with one pod deployed in the _applications_ namespace by _Application Developer B_. To expose the application to its clients (_Clients B_) via the host `b.example.com`, _Application Developer B_ creates _HTTPRoute B_ and attaches it to `Gateway AB`. -- _Public Endpoint_, which fronts the _NGF_ pod. This is typically a TCP load balancer (cloud, software, or hardware) or a combination of such load balancer with a NodePort service. _Clients A_ and _B_ connect to their applications via the _Public Endpoint_. +- Dynamic provisioning: When a new Gateway resource is created, the control plane automatically provisions a dedicated NGINX Deployment and exposes it using a Service. +- Configuration management: Kubernetes and Gateway API resources are translated into NGINX configurations, which are securely delivered to the data plane pods via a gRPC connection to the NGINX Agent. +- Secure communication: By default, the gRPC connection uses self-signed certificates generated during installation. Integration with [cert-manager](https://cert-manager.io/) is also supported for optional certificate management. -The yellow and purple arrows represent connections related to the client traffic, and the black arrows represent access to the Kubernetes API. The resources within the cluster are color-coded based on the user responsible for their creation. +### Data Plane: Autonomous Traffic Management -For example, the Cluster Operator is denoted by the color green, indicating they create and manage all the green resources. +Each NGINX data plane pod is provisioned as an independent Deployment containing an `nginx` container. This container runs both the `nginx` process and the [NGINX agent](https://github.com/nginx/agent), which is responsible for: ---- +- Applying configurations: The agent receives updates from the control plane and applies them to the NGINX instance. +- Handling reloads: NGINX Agent handles configuration reconciliation and reloading NGINX, eliminating the need for shared volumes or Unix signals between the control plane and data plane pods. + +With this design, multiple NGINX data planes can be managed by a single control plane, enabling fine-grained, Gateway-specific control and isolation. + +### Gateway Resource Management + +The architecture supports flexible operation and isolation across multiple Gateways: + +- Concurrent Gateways: Multiple Gateway objects can run simultaneously within a single installation. +- 1:1 resource mapping: Each Gateway resource corresponds uniquely to a dedicated data plane deployment, ensuring clear delineation of ownership and operational segregation. + +### Resilience and Fault Isolation + +One of the primary advantages of this architecture is enhanced operational resilience and fault isolation: + +#### Control Plane Resilience -## The NGINX Gateway Fabric pod +In the event of a control plane failure or downtime: +- Existing data plane pods continue serving traffic using their last-valid cached configurations. +- Updates to routes or Gateways are temporarily paused, but stable traffic delivery continues without degradation. +- Recovery restores functionality, resynchronizing configuration updates seamlessly. -NGINX Gateway Fabric consists of two containers: +#### Data Plane Resilience -1. `nginx`: the data plane. Consists of an NGINX master process and NGINX worker processes. The master process controls the worker processes. The worker processes handle the client traffic and load balance traffic to the backend applications. -1. `nginx-gateway`: the control plane. Watches Kubernetes objects and configures NGINX. +If a data plane pod encounters an outage or restarts: +- Only routes tied to the specific linked Gateway object experience brief disruptions. +- Configurations automatically resynchronize with the data plane upon pod restart, minimizing the scope of impact. +- Other data plane pods remain unaffected and continue serving traffic normally. -These containers are deployed in a single pod as a Kubernetes Deployment. +This split architecture ensures operational boundaries between the control plane and data plane, delivering improved scalability, security, and robustness while minimizing risks associated with failures in either component. -The `nginx-gateway`, or the control plane, is a [Kubernetes controller](https://kubernetes.io/docs/concepts/architecture/controller/), written with the [controller-runtime](https://github.com/kubernetes-sigs/controller-runtime) library. It watches Kubernetes objects (services, endpoints, secrets, and Gateway API CRDs), translates them to NGINX configuration, and configures NGINX. +--- -This configuration happens in two stages: +## High-Level Example of NGINX Gateway Fabric in Action + +This figure depicts an example of NGINX Gateway Fabric exposing three web applications within a Kubernetes cluster to clients on the internet: + +```mermaid +graph LR + %% Nodes and Relationships + subgraph KubernetesCluster[Kubernetes Cluster] + subgraph applications1[Namespace: applications] + + subgraph DataplaneComponentsAB[Dataplane Components] + GatewayAB[Gateway AB
Listener: *.example.com] + + subgraph NGINXPodAB[NGINX Pod] + subgraph NGINXContainerAB[NGINX Container] + NGINXProcessAB(NGINX) + NGINXAgentAB(NGINX Agent) + end + end + end + + subgraph HTTPRouteAAndApplicationA[HTTPRoute A and Application A] + HTTPRouteA[HTTPRoute A
Host: a.example.com] + ApplicationA[Application AB
Pods: 2] + end + + subgraph HTTPRouteBAndApplicationB[HTTPRoute B and Application B] + HTTPRouteB[HTTPRoute B
Host: b.example.com] + ApplicationB[Application B
Pods: 1] + end + end + + subgraph applications2[Namespace: applications2] + + subgraph DataplaneComponentsC[Dataplane Components] + GatewayC[Gateway C
Listener: *.other-example.com] + + subgraph NGINXPodC[NGINX Pod] + subgraph NGINXContainerC[NGINX Container] + NGINXProcessC(NGINX) + NGINXAgentC(NGINX Agent) + end + end + end + + subgraph HTTPRouteCAndApplicationC[HTTPRoute C and Application C] + HTTPRouteC[HTTPRoute C
Host: c.other-example.com] + ApplicationC[Application C
Pods: 1] + end + + end + + subgraph nginx-gateway[Namespace: nginx-gateway] + NGFPod[NGF Pod] + end + + KubernetesAPI[Kubernetes API] + end + + subgraph Users[Users] + ClusterOperator[Cluster Operator] + AppDevA[Application Developer A] + AppDevB[Application Developer B] + AppDevC[Application Developer C] + end + + subgraph Clients[Clients] + ClientsA[Clients A] + ClientsB[Clients B] + ClientsC[Clients C] + end + + subgraph "Public Endpoints" + PublicEndpointAB[Public Endpoint AB
TCP Load Balancer/NodePort] + PublicEndpointC[Public Endpoint C
TCP Load Balancer/NodePort] + end + + %% Updated Traffic Flow + ClientsA == a.example.com ==> PublicEndpointAB + ClientsB == b.example.com ==> PublicEndpointAB + ClientsC == c.other-example.com ==> PublicEndpointC + + PublicEndpointAB ==> NGINXProcessAB + PublicEndpointC ==> NGINXProcessC + NGINXProcessAB ==> ApplicationA + NGINXProcessAB ==> ApplicationB + NGINXProcessC ==> ApplicationC + + %% Kubernetes Configuration Flow + HTTPRouteA --> GatewayAB + HTTPRouteB --> GatewayAB + HTTPRouteC --> GatewayC + + NGFPod --> KubernetesAPI + NGFPod --gRPC--> NGINXAgentAB + NGINXAgentAB --> NGINXProcessAB + NGFPod --gRPC--> NGINXAgentC + NGINXAgentC --> NGINXProcessC + + ClusterOperator --> KubernetesAPI + AppDevA --> KubernetesAPI + AppDevB --> KubernetesAPI + AppDevC --> KubernetesAPI + + %% Styling + style ClusterOperator fill:#66CDAA,stroke:#333,stroke-width:2px + style GatewayAB fill:#66CDAA,stroke:#333,stroke-width:2px + style GatewayC fill:#66CDAA,stroke:#333,stroke-width:2px + style NGFPod fill:#66CDAA,stroke:#333,stroke-width:2px + + style NGINXProcessAB fill:#66CDAA,stroke:#333,stroke-width:2px + style NGINXProcessC fill:#66CDAA,stroke:#333,stroke-width:2px + + style KubernetesAPI fill:#8A2BE2,stroke:#333,stroke-width:2px + + style HTTPRouteAAndApplicationA fill:#E0FFFF,stroke:#333,stroke-width:2px + style HTTPRouteBAndApplicationB fill:#E0FFFF,stroke:#333,stroke-width:2px + + style AppDevA fill:#FFA07A,stroke:#333,stroke-width:2px + style HTTPRouteA fill:#FFA07A,stroke:#333,stroke-width:2px + style ApplicationA fill:#FFA07A,stroke:#333,stroke-width:2px + style ClientsA fill:#FFA07A,stroke:#333,stroke-width:2px + + style AppDevB fill:#87CEEB,stroke:#333,stroke-width:2px + style HTTPRouteB fill:#87CEEB,stroke:#333,stroke-width:2px + style ApplicationB fill:#87CEEB,stroke:#333,stroke-width:2px + style ClientsB fill:#87CEEB,stroke:#333,stroke-width:2px + + style AppDevC fill:#FFC0CB,stroke:#333,stroke-width:2px + style HTTPRouteC fill:#FFC0CB,stroke:#333,stroke-width:2px + style ApplicationC fill:#FFC0CB,stroke:#333,stroke-width:2px + style ClientsC fill:#FFC0CB,stroke:#333,stroke-width:2px + + style PublicEndpointAB fill:#FFD700,stroke:#333,stroke-width:2px + style PublicEndpointC fill:#FFD700,stroke:#333,stroke-width:2px + + %% Styling + classDef dashedSubgraph stroke-dasharray: 5, 5; + + %% Assign Custom Style Classes + class DataplaneComponentsAB dashedSubgraph; + class DataplaneComponentsC dashedSubgraph; +``` -1. NGINX configuration files are written to the NGINX configuration volume shared by the `nginx-gateway` and `nginx` containers. -1. The control plane reloads the NGINX process. +{{< note >}} The figure does not show many of the necessary Kubernetes resources the Cluster Operators and Application Developers need to create, like deployment and services. {{< /note >}} -This is possible because the two containers [share a process namespace](https://kubernetes.io/docs/tasks/configure-pod-container/share-process-namespace/), allowing the NGINX Gateway Fabric process to send signals to the NGINX main process. +The figure shows: -The following diagram represents the connections, relationships and interactions between process with the `nginx` and `nginx-gateway` containers, as well as external processes/entities. +- A _Kubernetes cluster_. +- Users _Cluster Operator_, _Application Developer A_, _B_ and _C_. These users interact with the cluster through the Kubernetes API by creating Kubernetes objects. +- _Clients A_, _B_, and _C_ connect to _Applications A_, _B_, and _C_ respectively, which the developers have deployed. +- The _NGF Pod_, [deployed by _Cluster Operator_]({{< ref "/ngf/installation">}}) in the namespace _nginx-gateway_. For scalability and availability, you can have multiple replicas. The _NGF_ container interacts with the Kubernetes API to retrieve the most up-to-date Gateway API resources created within the cluster. When a new Gateway resource is provisioned, the control plane dynamically creates and manages a corresponding NGINX data plane Deployment and Service. It watches the Kubernetes API and dynamically configures these _NGINX_ deployments based on the Gateway API resources, ensuring proper alignment between the cluster state and the NGINX configuration. +- The _NGINX Pod_ consists of an NGINX container and the integrated NGINX agent, which securely communicates with the control plane over gRPC. The control plane translates Gateway API resources into NGINX configuration, and sends the configuration to the agent. +- Gateways _Gateway AB_ and _Gateway C_, created by _Cluster Operator_, request points where traffic can be translated to Services within the cluster. _Gateway AB_, includes a listener with a hostname `*.example.com`. _Gateway C_, includes a listener with a hostname `*.other-example.com`. Application Developers have the ability to attach their application's routes to the _Gateway AB_ if their application's hostname matches `*.example.com`, or to _Gateway C_ if their application's hostname matches `*.other-example.com` +- _Application A_ with two pods deployed in the _applications_ namespace by _Application Developer A_. To expose the application to its clients (_Clients A_) via the host `a.example.com`, _Application Developer A_ creates _HTTPRoute A_ and attaches it to `Gateway AB`. +- _Application B_ with one pod deployed in the _applications_ namespace by _Application Developer B_. To expose the application to its clients (_Clients B_) via the host `b.example.com`, _Application Developer B_ creates _HTTPRoute B_ and attaches it to `Gateway AB`. +- _Application C_ with one pod deployed in the _applications2_ namespace by _Application Developer C_. To expose the application to its clients (_Clients C_) via the host `c.other-example.com`, _Application Developer C_ creates _HTTPRoute C_ and attaches it to `Gateway C`. +- _Public Endpoint AB_, and _Public Endpoint C_ and which fronts the _NGINX AB_, and _NGINX C_ pods respectively. A public endpoint is typically a TCP load balancer (cloud, software, or hardware) or a combination of such load balancer with a NodePort service. _Clients A_ and _B_ connect to their applications via the _Public Endpoint AB_, and _Clients C_ connect to their applications via the _Public Endpoint C_. +- The bold arrows represent connections related to the client traffic. Note that the traffic from _Clients C_ to _Application C_ is completely isolated from the traffic between _Clients A_ and _B_ and _Application A_ and _B_ respectively. -{{< img src="/ngf/img/ngf-pod.png" alt="" >}} +The resources within the cluster are color-coded based on the user responsible for their creation. +For example, the Cluster Operator is denoted by the color green, indicating they create and manage all the green resources. + +--- + +## NGINX Gateway Fabric: Component Communication Workflow + +```mermaid +graph LR + %% Main Components + KubernetesAPI[Kubernetes API] + PrometheusMonitor[Prometheus] + F5Telemetry[F5 Telemetry Service] + NGFPod[NGF Pod] + NGINXPod[NGINX Pod] + Client[Client] + Backend[Backend] + + %% NGINX Pod Grouping + subgraph NGINXPod[NGINX Pod] + NGINXAgent[NGINX Agent] + NGINXMaster[NGINX Master] + NGINXWorker[NGINX Worker] + ConfigFiles[Config Files] + ContainerRuntimeNGINX[stdout/stderr] + end + + subgraph NGFPod[NGF Pod] + NGFProcess[NGF Process] + ContainerRuntimeNGF[stdout/stderr] + end + + %% External Components Grouping + subgraph ExternalComponents[.] + KubernetesAPI[Kubernetes API] + PrometheusMonitor[Prometheus] + F5Telemetry[F5 Telemetry Service] + end + + %% HTTPS: Communication with Kubernetes API + NGFProcess -- "(1) Reads Updates" --> KubernetesAPI + NGFProcess -- "(1) Writes Statuses" --> KubernetesAPI + + %% Prometheus: Metrics Collection + PrometheusMonitor -- "(2) Fetches controller-runtime metrics" --> NGFPod + PrometheusMonitor -- "(5) Fetches NGINX metrics" --> NGINXWorker + + %% Telemetry: Product telemetry data + NGFProcess -- "(3) Sends telemetry data" --> F5Telemetry + + %% File I/O: Logging + NGFProcess -- "(4) Write logs" --> ContainerRuntimeNGF + NGINXMaster -- "(11) Write logs" --> ContainerRuntimeNGINX + NGINXWorker -- "(12) Write logs" --> ContainerRuntimeNGINX + + %% gRPC: Configuration Updates + NGFProcess -- "(6) Sends Config to Agent" --> NGINXAgent + NGINXAgent -- "(7) Validates & Writes Config & TLS Certs" --> ConfigFiles + NGINXAgent -- "(8) Reloads NGINX" --> NGINXMaster + NGINXAgent -- "(9) Sends DataPlaneResponse" --> NGFProcess + + %% File I/O: Configuration and Secrets + NGINXMaster -- "(10) Reads TLS Secrets" --> ConfigFiles + NGINXMaster -- "(11) Reads nginx.conf & NJS Modules" --> ConfigFiles + + %% Signals: Worker Lifecycle Management + NGINXMaster -- "(14) Manages Workers (Update/Shutdown)" --> NGINXWorker + + %% Traffic Flow + Client -- "(15) Sends Traffic" --> NGINXWorker + NGINXWorker -- "(16) Routes Traffic" --> Backend + + %% Styling + classDef important fill:#66CDAA,stroke:#333,stroke-width:2px; + classDef metrics fill:#FFC0CB,stroke:#333,stroke-width:2px; + classDef io fill:#FFD700,stroke:#333,stroke-width:2px; + classDef signal fill:#87CEEB,stroke:#333,stroke-width:2px; + style ExternalComponents fill:transparent,stroke-width:0px + + %% Class Assignments for Node Colors + class NGFPod,KubernetesAPI important; + class PrometheusMonitor,F5Telemetry metrics; + class ConfigFiles,NGINXMaster,NGINXWorker,NGINXAgent io; + class Client,Backend signal; +``` The following list describes the connections, preceeded by their types in parentheses. For brevity, the suffix "process" has been omitted from the process descriptions. 1. (HTTPS) - Read: _NGF_ reads the _Kubernetes API_ to get the latest versions of the resources in the cluster. - Write: _NGF_ writes to the _Kubernetes API_ to update the handled resources' statuses and emit events. If there's more than one replica of _NGF_ and [leader election](https://github.com/nginx/nginx-gateway-fabric/tree/v1.6.1/charts/nginx-gateway-fabric#configuration) is enabled, only the _NGF_ pod that is leading will write statuses to the _Kubernetes API_. -1. (HTTP, HTTPS) _Prometheus_ fetches the `controller-runtime` and NGINX metrics via an HTTP endpoint that _NGF_ exposes (`:9113/metrics` by default). Prometheus is **not** required by NGINX Gateway Fabric, and its endpoint can be turned off. -1. (File I/O) - - Write: _NGF_ generates NGINX _configuration_ based on the cluster resources and writes them as `.conf` files to the mounted `nginx-conf` volume, located at `/etc/nginx/conf.d`. It also writes _TLS certificates_ and _keys_ from [TLS secrets](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets) referenced in the accepted Gateway resource to the `nginx-secrets` volume at the path `/etc/nginx/secrets`. - - Read: _NGF_ reads the PID file `nginx.pid` from the `nginx-run` volume, located at `/var/run/nginx`. _NGF_ extracts the PID of the nginx process from this file in order to send reload signals to _NGINX master_. +1. (HTTP, HTTPS) _Prometheus_ fetches the `controller-runtime` metrics via an HTTP endpoint that _NGF_ exposes (`:9113/metrics` by default). +Prometheus is **not** required by NGINX Gateway Fabric, and its endpoint can be turned off. +1. (HTTPS) NGF sends [product telemetry data]({{< ref "/ngf/overview/product-telemetry.md" >}}) to the F5 telemetry service. 1. (File I/O) _NGF_ writes logs to its _stdout_ and _stderr_, which are collected by the container runtime. -1. (HTTP) _NGF_ fetches the NGINX metrics via the unix:/var/run/nginx/nginx-status.sock UNIX socket and converts it to _Prometheus_ format used in #2. -1. (Signal) To reload NGINX, _NGF_ sends the [reload signal](https://nginx.org/en/docs/control.html) to the **NGINX master**. +1. (HTTP, HTTPS) _Prometheus_ fetches the NGINX metrics via an HTTP endpoint that _NGINX_ exposes (`:9113/metrics` by default). Prometheus is **not** required by NGINX, and its endpoint can be turned off. +1. (gRPC) _NGF_ generates NGINX _configuration_ based on the cluster resources and sends them to _NGINX Agent_ over a secure gRPC connection. + - NGF sends a message containing file metadata to all pods (subscriptions) for the deployment. + - Agent receives a ConfigApplyRequest with the list of file metadata. + - Agent calls GetFile for each file in the list, which NGF sends back to the agent. +1. (File I/O) + - Write: __NGINX Agent_ validates the received configuration, and then writes and applies the config if valid. It also writes _TLS certificates_ and _keys_ from [TLS secrets](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets) referenced in the accepted Gateway resource. +1. (Signal) To reload NGINX, Agent sends the reload signal to the NGINX master. +1. (gRPC) Agent responds to NGF with a DataPlaneResponse. 1. (File I/O) - - Write: The _NGINX master_ writes its PID to the `nginx.pid` file stored in the `nginx-run` volume. - - Read: The _NGINX master_ reads _configuration files_ and the _TLS cert and keys_ referenced in the configuration when it starts or during a reload. These files, certificates, and keys are stored in the `nginx-conf` and `nginx-secrets` volumes that are mounted to both the `nginx-gateway` and `nginx` containers. + - Read: The _NGINX master_ reads _configuration files_ and the _TLS cert and keys_ referenced in the configuration when it starts or during a reload. 1. (File I/O) - - Write: The _NGINX master_ writes to the auxiliary Unix sockets folder, which is located in the `/var/run/nginx` - directory. - Read: The _NGINX master_ reads the `nginx.conf` file from the `/etc/nginx` directory. This [file](https://github.com/nginx/nginx-gateway-fabric/blob/v1.6.1/internal/mode/static/nginx/conf/nginx.conf) contains the global and http configuration settings for NGINX. In addition, _NGINX master_ reads the NJS modules referenced in the configuration when it starts or during a reload. NJS modules are stored in the `/usr/lib/nginx/modules` directory. 1. (File I/O) The _NGINX master_ sends logs to its _stdout_ and _stderr_, which are collected by the container runtime. 1. (File I/O) An _NGINX worker_ writes logs to its _stdout_ and _stderr_, which are collected by the container runtime. 1. (Signal) The _NGINX master_ controls the [lifecycle of _NGINX workers_](https://nginx.org/en/docs/control.html#reconfiguration) it creates workers with the new configuration and shutdowns workers with the old configuration. -1. (HTTP) To consider a configuration reload a success, _NGF_ ensures that at least one NGINX worker has the new configuration. To do that, _NGF_ checks a particular endpoint via the unix:/var/run/nginx/nginx-config-version.sock UNIX socket. 1. (HTTP, HTTPS) A _client_ sends traffic to and receives traffic from any of the _NGINX workers_ on ports 80 and 443. 1. (HTTP, HTTPS) An _NGINX worker_ sends traffic to and receives traffic from the _backends_. -Below are additional connections not depcited on the diagram: - -- (HTTPS) NGF sends [product telemetry data]({{< ref "/ngf/overview/product-telemetry.md" >}}) to the F5 telemetry service. - --- ### Differences with NGINX Plus @@ -123,6 +374,4 @@ The normal process to update any changes to NGINX is to write the configuration ## Pod readiness -The `nginx-gateway` container includes a readiness endpoint available through the path `/readyz`. A [readiness probe](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes) periodically checks the endpoint on startup, returning a `200 OK` response when the pod can accept traffic for the data plane. Once the control plane successfully starts, the pod becomes ready. - -If there are relevant Gateway API resources in the cluster, the control plane will generate the first NGINX configuration and successfully reload NGINX before the pod is considered ready. +The `nginx-gateway` container exposes a readiness endpoint at `/readyz`. During startup, a [readiness probe](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes) periodically checks this endpoint. The probe returns a `200 OK` response once the control plane initializes successfully and is ready to begin configuring NGINX. At that point, the pod is marked as ready. diff --git a/static/ngf/img/ngf-high-level.png b/static/ngf/img/ngf-high-level.png deleted file mode 100644 index 6f2bef6f0..000000000 Binary files a/static/ngf/img/ngf-high-level.png and /dev/null differ diff --git a/static/ngf/img/ngf-pod.png b/static/ngf/img/ngf-pod.png deleted file mode 100644 index d7b67e5b0..000000000 Binary files a/static/ngf/img/ngf-pod.png and /dev/null differ