Hello,
I am deploying a Kubernetes cluster using NVIDIA BCM (Bright Cluster Manager) based on the reference architecture with 3 control-plane nodes and multiple worker nodes.
During BCM installation, when Network Type 1 is selected, the cluster is fully isolated by design. In this topology, external access to control-plane or worker nodes is not possible directly, and all access must go through the BCM head node.
This becomes challenging when running Kubernetes workloads that are expected to be accessed externally (for example via Ingress, services, or application UIs):
- In Type 1, external access requires:
- Assigning an additional IP address on the BCM head node
- Running a reverse proxy or NAT (DNAT/SNAT) on the head node
- Forwarding traffic manually to Kubernetes services (Ingress / MetalLB IPs, etc.)
- As the number of applications increases, this approach creates:
- Operational overhead on the head node
- Tight coupling between cluster networking and application exposure
- Additional HA and failover complexity for the reverse proxy/NAT layer
Given this scenario, I would like to ask:
- Is there a recommended or best-practice approach for exposing Kubernetes workloads when using BCM Network Type 1?
- For example, supported patterns involving Ingress, MetalLB, or BCM-native networking features
- Or guidance on minimizing per-application reverse proxy/NAT configuration on the head node
- If regular external access to Kubernetes workloads is a core requirement, is it generally recommended to:
- Prefer Network Type 2 instead of Type 1?
- Treat Type 1 as suitable mainly for fully isolated HPC-style workloads rather than service-oriented Kubernetes use cases?
- Are there any official NVIDIA recommendations or reference designs for:
- Kubernetes + BCM deployments where multiple user-facing applications must be exposed externally
- Balancing security isolation with operational simplicity in this context
Any guidance, design patterns, or references would be greatly appreciated.
Thank you.