Skip to content

Remove cert manager install section #452

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
akhomyakov merged 2 commits into from
Sep 18, 2026
Merged

Remove cert manager install section #452

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
9096dc3
Minor copy edits
Sep 17, 2026
a46adfa
Remove cert manager section
Sep 18, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 2 additions & 30 deletions installation/controller-k3s-air-gap-ha.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -525,37 +525,9 @@ Expected output:
netris-controller-initdb-09-dhcp-option-set-jq7wl 0/1 Completed 0 58s




11. (Optional) Enable SSL with cert-manager
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

If you intend to secure the Controller via an FQDN and Let's Encrypt (or another ACME issuer) please also install cert-manager:

1. Install cert-manager:

.. code-block:: shell

kubectl apply -f manifests/netris-controller/cert-manager.yaml


2. Verify pods:


.. code-block:: shell

kubectl get pods -n cert-manager


3. Apply cert-manager resources (ClusterIssuers, etc.):

.. code-block:: shell

kubectl apply -f manifests/netris-controller/cert-manager-resources.yaml

.. _install-local-repo:

13. Set Up the Local Netris Repository
11. Set Up the Local Netris Repository
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The Netris Local Repository is essential for environments where switches, softgates, or other infrastructure devices do not have direct access to the internet. By setting up a local repository, you ensure that these devices can still download necessary packages and updates through a local APT repository
Expand Down Expand Up @@ -584,7 +556,7 @@ The Netris Local Repository is essential for environments where switches, softga



14. Validate Your Deployment
12. Validate Your Deployment
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

- **Access the Netris Controller** via https://192.168.0.50 (or your assigned FQDN).
Expand Down
10 changes: 5 additions & 5 deletions introduction.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,11 +33,11 @@ A traditional enterprise or cloud data center is typically built around a single

* **North-South (frontend) fabric.** The Ethernet fabric that connects the data center to the outside world — ISPs, peering, the corporate WAN, the public Internet, other regions — and that also carries tenant API traffic, storage traffic, and the data path for ingress and egress services such as NAT and L4 load balancing. The frontend fabric is the closest analog to the fabric you would find in a traditional data center. Some teams call this the *frontend network*.

* **East-West (backend, scale-out) fabric.** A dedicated, high-bandwidth, lossless network that connects GPU servers directly to each other for collective communications — the all-reduce, all-gather, and all-to-all traffic patterns generated by distributed training and large-model inference. The backend fabric carries no client traffic and is sized very differently from the frontend. It can be implemented over Ethernet (e.g., NVIDIA Spectrum-X), or over InfiniBand using NVIDIA Quantum. Netris manages both. Some teams call this the *backend network* or *scale-out network*.
* **East-West (backend, scale-out) fabric.** A dedicated, high-bandwidth, lossless network that connects GPU servers directly to each other for collective communications — the all-reduce, all-gather, and all-to-all traffic patterns generated by distributed training and large-model inference. The backend fabric carries no client traffic and is sized very differently from the frontend. It can be implemented over Ethernet (e.g., NVIDIA Spectrum-X), or using NVIDIA Quantum InfiniBand. Netris supports both options. Some teams call this the *backend network* or *scale-out network*.

* **NVL72 (rack-scale, scale-up) fabric.** An NVLink-based, in-rack fabric that connects up to 72 GPUs in a single liquid-cooled rack into one NVLink domain, so the rack behaves as a single logical accelerator. NVL72 ships with NVIDIA GB200 NVL72 and GB300 NVL72 rack-scale systems. NVLink switching inside the rack is managed by NVIDIA NMX (NVLink Management Software).
* **NVL72 (rack-scale, scale-up) fabric.** An NVLink-based, in-rack fabric that connects up to 72 GPUs in a single liquid-cooled rack into one NVLink domain, so the rack behaves as a single logical accelerator. NVL72 ships with NVIDIA GB200 NVL72 and GB300 NVL72 rack-scale systems. NVLink switching inside the rack is managed by NVIDIA NMX (NVLink Management Software), and Netris integrates with NMX to manage GPU partitions on NVL72 fabrics alongside the rest of the network.

* **Out-of-band (OOB) management fabric.** A separate management network used to reach the management interfaces of every device in the deployment — Ethernet switches, InfiniBand switches, NVLink switches, DPUs, server BMC/IPMI, PDUs, environmental controllers, and orchestration platforms. The OOB fabric carries no tenant traffic. It can be deployed as part of the North-South fabric or as a standalone fabric, depending on the operator's availability objectives.
* **Out-of-band (OOB) management fabric.** A separate management network used to reach the management interfaces of every device in the deployment — Ethernet switches, NVIDIA Quantum InfiniBand switches, NVLink switches, DPUs, server BMC/IPMI, PDUs, environmental controllers, and orchestration platforms. The OOB fabric carries no tenant traffic. It can be deployed as part of the North-South fabric or as a standalone fabric, depending on the operator's availability objectives.

The two diagrams below show how these fabrics fit together in two common Netris deployments. The only structural difference between them is the technology used for the East-West backend fabric.

Expand All @@ -48,12 +48,12 @@ The two diagrams below show how these fabrics fit together in two common Netris

The East-West fabric is Ethernet (e.g., NVIDIA Spectrum-X). Netris manages both the North-South frontend fabric and the East-West Ethernet backend fabric. A Netris Switch Agent runs on every Netris-managed switch, applying controller intent locally and reporting telemetry back to the controller. Netris SoftGate provides ingress and egress services (NAT, L4 load balancing) at the edge of the North-South fabric. The Netris Controller sits outside the data path and reaches every managed device through closed-loop telemetry and configuration channels over the OOB management network. Netris integrates with NMX to orchestrate NVLink partitions for tenant isolation when an NVL72 fabric is present.

**Reference architecture — InfiniBand backend (NVIDIA Quantum)**
**Reference architecture — NVIDIA Quantum InfiniBand backend**

.. image:: images/Netris-RA-Hybrid-Ethernet-InfiniBand.png
:align: center

The East-West fabric is InfiniBand, running NVIDIA Quantum. Netris manages the North-South Ethernet frontend fabric directly and integrates with NVIDIA UFM (Unified Fabric Manager) to orchestrate tenant isolation (PKeys) on the InfiniBand fabric. The rest of the architecture — Netris Switch Agents on the Netris-managed Ethernet switches, SoftGate, Controller, OOB, and integration with NMX for NVL72 management — is identical to the Ethernet-backend deployment.
The East-West fabric is NVIDIA Quantum InfiniBand. Netris manages the North-South Ethernet frontend fabric directly and integrates with NVIDIA UFM (Unified Fabric Manager) to orchestrate tenant isolation (PKeys) on the NVIDIA Quantum InfiniBand fabric. The rest of the architecture — Netris Switch Agents on the Netris-managed Ethernet switches, SoftGate, Controller, OOB, and integration with NMX for NVL72 management — is identical to the Ethernet-backend deployment.

What to read next
-----------------
Expand Down
12 changes: 6 additions & 6 deletions netris-architecture.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,11 +25,11 @@ These three components are present in every Netris deployment. If you are runnin
AI components (additive, when a GPU cluster is present)
========================================================

If your deployment includes a GPU cluster — an East-West Ethernet backend fabric (e.g., NVIDIA Spectrum-X), an East-West Quantum InfiniBand backend fabric, an NVL72 rack-scale fabric, or BlueField DPUs in your servers — Netris adds the following components on top of the core platform:
If your deployment includes a GPU cluster — an East-West Ethernet backend fabric (e.g., NVIDIA Spectrum-X), an NVIDIA Quantum InfiniBand backend fabric, an NVL72 rack-scale fabric, or BlueField DPUs in your servers — Netris offers the following optional components on top of the core platform:

* **NVIDIA BlueField DPUs** — managed by Netris as first-class network devices participating in the EVPN/VXLAN fabric for hard isolation (enforced on networking hardware) on the server itself. See :doc:`BlueField-3 DPUs <bluefield-3-dpus>`.
* **NVIDIA BlueField DPUs** — added by Netris as first-class endpoints (VTEPs) in the EVPN/VXLAN fabric, extending hard isolation (enforced on networking hardware) onto the server itself. See :doc:`BlueField-3 DPUs <bluefield-3-dpus>`.

* **NVIDIA UFM integration** — for automated InfiniBand partition (PKey) management on Quantum backend fabrics. See :doc:`UFM Integration <netris-ufm-integration>`.
* **NVIDIA UFM integration** — for automated partition key (PKey) management on NVIDIA Quantum InfiniBand backend fabrics. See :doc:`UFM Integration <netris-ufm-integration>`.

* **NVIDIA NMX integration** — for automated NVLink partition management on NVL72 rack-scale fabrics (GB200 NVL72 and GB300 NVL72). See :doc:`NMX Integration <netris-nvlink-integration>`.

Expand Down Expand Up @@ -92,7 +92,7 @@ Netris deployments use dedicated management networks that separate automation in

* **Seed switches.** A set of 2 to 6 Netris-managed switches provisioned before any other Netris-managed switches. Seed switches connect directly to CMN and form the root of the OOB management hierarchy in larger deployments. Whether seed switches are used depends on the deployment topology described below.

* **Out-of-Band Management Network (OOB):** A management aggregation network composed of OOB switches. The OOB network hosts management connectivity for Netris-managed network fabrics. In many deployments, the OOB network also hosts management connectivity for Server Management Interfaces (SMI), Data Processing Units (DPUs), Infrastructure Control Platforms (ICP), InfiniBand (IB) switches, NVLink switches, and Data Center Infrastructure Management (DCIM) systems. The OOB network may be implemented as part of the North–South fabric or as a standalone network fabric and can be Netris-managed or operator-managed (not Netris-managed) depending on the operator's objectives.
* **Out-of-Band Management Network (OOB):** A management aggregation network composed of OOB switches. The OOB network hosts management connectivity for Netris-managed network fabrics. In many deployments, the OOB network also hosts management connectivity for Server Management Interfaces (SMI), Data Processing Units (DPUs), Infrastructure Control Platforms (ICP), NVIDIA Quantum InfiniBand switches, NVLink switches, and Data Center Infrastructure Management (DCIM) systems. The OOB network may be implemented as part of the North–South fabric or as a standalone network fabric and can be Netris-managed or operator-managed (not Netris-managed) depending on the operator's objectives.

**Deployment topologies.** Building on the management networks above, Netris supports two physical topologies for connecting Netris-managed switches to the controller:

Expand Down Expand Up @@ -123,7 +123,7 @@ Netris is built on the following security design principles:

* **Control Plane Independence:** Once configuration is applied, network devices enforce policies independently of the controller. Loss of the controller does not disrupt tenant traffic or compromise isolation.

* **Hard isolation (enforced on networking hardware):** Tenant isolation is implemented through the underlying infrastructure hardware -- VRF, VXLAN, and ACLs in Ethernet fabrics; InfiniBand partition keys (PKeys); and NVLink GPU fabric partitions. Netris automates the provisioning of these mechanisms and does not rely on software overlays for tenant separation.
* **Hard isolation (enforced on networking hardware):** Tenant isolation is implemented through the underlying infrastructure hardware -- VRF, VXLAN, and ACLs in Ethernet fabrics; partition keys (PKeys) on NVIDIA Quantum InfiniBand; and NVLink GPU fabric partitions. Netris automates the provisioning of these mechanisms and does not rely on software overlays for tenant separation.

* **Customer-Controlled Security Boundary:** Because the Netris Controller is deployed within the customer's environment, organizations retain full control over the security perimeter. Netris does not offer hosted control planes.

Expand All @@ -141,7 +141,7 @@ Security of the overall infrastructure environment is a shared responsibility be
* Role-based access control (:doc:`accounts`)
* Infrastructure configuration enforcement
* Audit logging (:doc:`monitoring-observability/visibility`)
* Tenant isolation orchestration across Ethernet, InfiniBand, and NVLink fabrics
* Tenant isolation orchestration across Ethernet, NVIDIA Quantum InfiniBand, and NVLink fabrics
* Device management hardening via :doc:`Inventory Profiles <inventory-profile>`

**Organizations deploying Netris are responsible for:**
Expand Down
Loading