Skip to content

Commit a65d0d5

Browse files
authored
Added load balancer instructions for the NFS Server Provisioner (#212)
Signed-off-by: Michael Mattsson <[email protected]>
1 parent 7cb5bac commit a65d0d5

File tree

3 files changed

+88
-1
lines changed

3 files changed

+88
-1
lines changed

docs/csi_driver/operations.md

+86
Original file line numberDiff line numberDiff line change
@@ -454,3 +454,89 @@ While both disabling conformance and configuration parameters lends itself to a
454454
<!--
455455
yum install -y iscsi-initiator-utils device-mapper-multipath iscsi-initiator-utils-iscsiuio nfs-utils
456456
-->
457+
458+
## Expose NFS Services Outside of the Kubernetes Cluster
459+
460+
In certain situations it's practical to expose the NFS exports outside the Kubernetes cluster to allow external applications to access data as part of an ETL (Extract, Transform, Load) pipeline or similar.
461+
462+
Since this is an untested feature with questionable security standards, HPE does not recommend using this facility in production at this time. Reach out to your HPE account representative if this is a critical feature for your workloads.
463+
464+
!!! danger
465+
The exports on the NFS servers does not have any network Access Control Lists (ACL) without root squash. Anyone with an NFS client that can reach the load balancer IP address have full access to the filesystem.
466+
467+
### From ClusterIP to LoadBalancer
468+
469+
The NFS server `Service` must be transformed into a "LoadBalancer".
470+
471+
In this example we'll assume a "RWX" `PersistentVolumeClaim` named "my-pvc-1" and NFS resources deployed in the default `Namespace`, "hpe-nfs".
472+
473+
Retrieve NFS UUID
474+
475+
```text
476+
export UUID=$(kubectl get pvc my-pvc-1 -o jsonpath='{.spec.volumeName}{"\n"}' | awk -Fpvc- '{print $2}')
477+
```
478+
479+
Patch the NFS `Service`:
480+
```text
481+
kubectl patch -n hpe-nfs svc/hpe-nfs-${UUID} -p '{"spec":{"type": "LoadBalancer"}}'
482+
```
483+
484+
The `Service` will be assigned an external IP address by the load balancer deployed in the cluster. If there is no load balancer deployed, a MetalLB example is provided below.
485+
486+
### MetalLB Example
487+
488+
Deploying MetalLB is outside the scope of this document. In this example, MetalLB was deployed on OpenShift 4.16 (Kubernetes v1.29) using the Operator provided by Red Hat in the "metallb-system" `Namespace`.
489+
490+
Determine the IP address range that will be assigned to the load balancers. In this example, 192.168.1.40 to 192.168.1.60 is being used. Note that the worker nodes in this cluster already have reachable IP addresses in the 192.168.1.0/24 network, which is a requirement.
491+
492+
Create the MetalLB instances, IP address pool and Layer 2 advertisement.
493+
494+
```text
495+
---
496+
apiVersion: metallb.io/v1beta1
497+
kind: MetalLB
498+
metadata:
499+
name: metallb
500+
namespace: metallb-system
501+
502+
---
503+
apiVersion: metallb.io/v1beta1
504+
kind: IPAddressPool
505+
metadata:
506+
namespace: metallb-system
507+
name: hpe-nfs-servers
508+
spec:
509+
protocol: layer2
510+
addresses:
511+
- 192.168.1.40-192.168.1.60
512+
513+
---
514+
apiVersion: metallb.io/v1beta1
515+
kind: L2Advertisement
516+
metadata:
517+
name: l2advertisement
518+
namespace: metallb-system
519+
spec:
520+
ipAddressPools:
521+
- hpe-nfs-servers
522+
```
523+
524+
Shortly, the external IP address of the NFS `Service` patched in the previous steps should have an IP address assigned.
525+
526+
```text
527+
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)
528+
hpe-nfs-UUID LoadBalancer 172.30.217.203 192.168.1.40 <long list of ports>
529+
```
530+
531+
### Mount the NFS Server from an NFS Client
532+
533+
Mounting the NFS export externally is now possible.
534+
535+
As root:
536+
537+
```text
538+
mount -t nfs4 192.168.1.40:/export /mnt
539+
```
540+
541+
!!! note
542+
If the NFS server is rescheduled in the Kubernetes cluster, the load balancer IP address follows, and the client will recover and resume IO after a few minutes.

docs/csi_driver/using.md

+1
Original file line numberDiff line numberDiff line change
@@ -950,6 +950,7 @@ These are some common issues and gotchas that are useful to know about when plan
950950
- Using ext4 as the backing filesystem has shown better performance with simultaneous writers to the same file.
951951
- Additional configuration and considerations may be required when using the NFS Server Provisioner with Red Hat OpenShift. See [NFS Server Provisioner Considerations](../partners/redhat_openshift/index.md#nfs_server_provisioner_considerations) for OpenShift.
952952
- XFS has proven troublesome to use as a backend "RWO" volume filesystem, leaving stale NFS handles for clients. Use ext4 as the "csi.storage.k8s.io/fstype" `StorageClass` parameter for best results.
953+
- The NFS servers provide a "ClusterIP" `Service`. It is possible to expose the NFS servers outside the cluster for external NFS clients. Understand the scope and limitations in [Auxillary Operations](operations.md#expose_nfs_services_outside_of_the_kubernetes_cluster).
953954

954955
See [diagnosing NFS Server Provisioner issues](diagnostics.md#nfs_server_provisioner_resources) for further details.
955956

docs/partners/redhat_openshift/index.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -243,7 +243,7 @@ Please refer to the OLM Lifecycle Manager documentation on how to safely [Uninst
243243

244244
# NFS Server Provisioner Considerations
245245

246-
When deploying NFS servers on OpenShift there's currently two things to keep in mind for a successful deployment.
246+
When deploying NFS servers on OpenShift there's currently two things to keep in mind for a successful deployment. Also, be understood with the [Limitations and Considerations for the NFS Server Provisioner](../../csi_driver/using.md#limitations_and_considerations_for_the_nfs_server_provisioner) in general.
247247

248248
## Non-standard hpe-nfs Namespace
249249

0 commit comments

Comments
 (0)