Open
Description
Overview
Include docs for including instances of NIC / NGF into the NGINX One Console
Description
Write a high-level summary of changes expected in this release.
Reference to Figma WiP
User stories
As a user, I need to see:
- The new dashboard for the "Control Plane"
- Lists of versions (so far, of NGF, NIC)
- Lists of CVEs
- Use of CVEs
- Number of impacted "control plane"
- List
- Versions (NIC, NGF)
- For APIs, note the related "instance metadata" (which really isn't metadata)
- Kubernetes Cluster UUID.
- Control Plane Deployment UUID.
- Deployment Name (user-facing identifier).
- Control Plane Identification (string), matching the values used for Entitlement & Visibility when possible.
- Control Plane Version (string), macthing the values used for Entitlement & Visibility when possible.
- Kubernetes Namespace (user-facing identifier).
Open question: IA. Options:
- Separate use case for incorporating NIC/NGF
- Incorporate them with other "instances"
- Separate page in this part of the ToC: https://docs-dev.nginx.com/nginx-one/nginx-configs
Unknown (to me). NGINX configuration from the NGINX One Console UI
- Release 1: read-only
- Will need some doc to explain
- With links to "how to" edit config for both NIC and NGF
- Will there be a future release where NIC/NGF configs can be managed
- Can we include NIC/NGF as part of Config Sync Groups
Possible ToC: (Applies to NIC/NGF only, NOT all k8s deployments)
Tasks
Create a simple list of tasks necessary for this content plan. Finer details can be kept to sub-issues.
Each task item should have a 1:1 relationship with a documentation item, which could be an engineering issue.
Layout:
- "Integrate Kubernetes deployments"
- How to install agent
- Link (or includes) for how to add a K8s deployment to N1C
- Agent v3 ONLY
- Table with list of k8s systems w and w/o
- "NIC/NGF Control Plane"
- Contrast with NGINX Agent Control Plane
- Review your CVEs
- Manage with the API
- Add to N1C reference doc
Issues
Define the differences between k8s "control plane" and an NGINX Agent "control plane" in the Glossary.
- Key points:
- NIC / NIC == 1:1
- NGF / NGF == 1: many
Archive info, for the trivial cases where the differences actually matter
Per F5 ChatGPT:
Kubernetes Control Plane
In Kubernetes, the control plane is a foundational component of the cluster responsible for managing and orchestrating the cluster's desired state. It serves as the "brain" of Kubernetes and ensures that workloads and resources in the cluster are configured and running as expected. The control plane typically consists of several core components:
1. API Server:
Exposes the Kubernetes API to users, CLI, and other components.
Accepts commands and configuration from users (via kubectl or other tools).
1. Etcd:
A distributed key-value store that serves as Kubernetes' persistent backing store.
Stores all cluster data (e.g., resource states, configuration).
1. Controller Manager:
Manages control loops that regulate the system's behavior by always driving the actual state towards the desired state (e.g., deployment scaling, pod health checks).
1. Scheduler:
Assigns workloads (Pods) to nodes based on resource availability, affinity rules, and other constraints.
1. Cloud Controller Manager (optional):
Integrates Kubernetes with cloud provider APIs (e.g., managing load balancers, storage volumes).
Kubernetes control plane is crucial for cluster operations, but it doesn't directly interact with applications or workloads—that task falls to the worker nodes (data plane).
NGINX Agent Control Plane
In the context of the NGINX Agent, the control plane refers to components used to manage, configure, and monitor NGINX instances remotely, often as part of a distributed network or application delivery environment. This concept applies more broadly to how "control" is exerted over your NGINX instances.
For example, in environments that use NGINX Agents (e.g., as part of NGINX Management Suite or NGINX Plus), the control plane is responsible for managing:
- Configuration Control:
- Pushes policies and settings to NGINX instances, allowing centralized management of upstream servers, routes, SSL settings, etc.
- Monitoring and Observability:
- Collects metrics, logs, and performance data from NGINX instances.
- Helps operators gain visibility into the health and performance of NGINX-managed services.
- Lifecycle Management:
- Provides tools for provisioning, updating, restarting, or reconfiguring NGINX instances.
-
Unlike the Kubernetes control plane, the NGINX Agent control plane uses a direct integration with NGINX instances to manage their runtime behavior and settings.
| Feature | Kubernetes Control Plane | NGINX Agent Control Plane |
|---|---|---|
| Purpose | Cluster orchestration and resource management | Remote management, monitoring, and operation of NGINX instances |
| Scope | Manages Kubernetes worker nodes and workloads | Manages individual or distributed NGINX instances |
| Components | API Server, Etcd, Scheduler, Controller Manager | NGINX Agent, NGINX Management Suite |
| Domain | Containers and microservices orchestration | Load balancing, application delivery, and web services |
| Interaction with Data Plane | Indirect (via worker nodes and kubelets) | Direct (via NGINX instances) |
Overview
Include docs for including instances of NIC / NGF into the NGINX One Console
Description
Write a high-level summary of changes expected in this release.
Reference to Figma WiP
User stories
As a user, I need to see:
- The new dashboard for the "Control Plane"
- Lists of versions (so far, of NGF, NIC)
- Lists of CVEs
- Use of CVEs
- Number of impacted "control plane"
- List
- Versions (NIC, NGF)
- For APIs, note the related "instance metadata" (which really isn't metadata)
- Kubernetes Cluster UUID.
- Control Plane Deployment UUID.
- Deployment Name (user-facing identifier).
- Control Plane Identification (string), matching the values used for Entitlement & Visibility when possible.
- Control Plane Version (string), macthing the values used for Entitlement & Visibility when possible.
- Kubernetes Namespace (user-facing identifier).
- Install Agent instructions
Open question: IA. Options:
- Separate use case for incorporating NIC/NGF
- Incorporate them with other "instances"
- Separate page in this part of the ToC: https://docs-dev.nginx.com/nginx-one/nginx-configs
Unknown (to me). NGINX configuration from the NGINX One Console UI
- Release 1: read-only
- Will need some doc to explain
- With links to "how to" edit config for both NIC and NGF
- Will there be a future release where NIC/NGF configs can be managed
- Can we include NIC/NGF as part of Config Sync Groups
Possible ToC: (Applies to NIC/NGF only, NOT all k8s deployments)
Tasks
Create a simple list of tasks necessary for this content plan. Finer details can be kept to sub-issues.
Each task item should have a 1:1 relationship with a documentation item, which could be an engineering issue.
- Update changelog/release notes
- Update instance info. New page for NIC/NGF
- Update definitions. Compare NIC/NGF control planes. Maybe in the glossary.
- Update API reference docs. Already reviewed https://gitlab.com/f5/nginx/one/saas/control-plane/-/merge_requests/3433
- Also set up API use cases