惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

V
Visual Studio Blog
博客园 - 司徒正美
Hugging Face - Blog
Hugging Face - Blog
博客园 - 叶小钗
The Cloudflare Blog
D
DataBreaches.Net
J
Java Code Geeks
G
Google Developers Blog
L
LangChain Blog
N
Netflix TechBlog - Medium
Stack Overflow Blog
Stack Overflow Blog
月光博客
月光博客
酷 壳 – CoolShell
酷 壳 – CoolShell
WordPress大学
WordPress大学
小众软件
小众软件
量子位
Apple Machine Learning Research
Apple Machine Learning Research
P
Proofpoint News Feed
博客园_首页
罗磊的独立博客
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
B
Blog
腾讯CDC

OneUptime Blog

How to Monitor Azure App Services (PaaS) with OpenTelemetry Grafana Stack vs OneUptime: DIY Observability or Unified Platform? Your AI Workloads Are About to Blow Up Your Observability Bill The Great Observability Consolidation Is Here How to Write Custom Object Classes for Ceph How to Write Custom Ceph Manager Modules How to Write a ceph.conf Configuration File How to Use Rook-Ceph with OpenShift How to Use Rook-Ceph with Longhorn for Comparison How to Configure Volume Snapshot Class for RBD in Rook How to Configure VolumeReplicationClass Scheduling Intervals in Rook How to Set Up Volume Replication with Rook-Ceph How to Create Volume Group Snapshots with Rook CSI How to Visualize Ceph Network Performance in Grafana How to Enable Virtual Host-Style Bucket Access in Rook How to View Runtime Configuration via Admin Socket How to View Quota Settings and Update Stats in Ceph RGW How to View PG Scaling Recommendations with autoscale-status How to View PG Distribution via Admin Socket How to View Performance Metrics in the Ceph Dashboard How to View OSD Performance Counters in Ceph How to View Connection Status via Admin Socket How to View Ceph Cluster Summary Dashboard via CLI How to Version Control Rook-Ceph Configuration How to Version Control Ceph Infrastructure with Terraform How to Verify Kubernetes Node Requirements for Rook-Ceph Deployment How to Verify Health Before and After Rook Upgrades How to Verify Data Integrity with Deep Scrubbing How to Verify Complete Rook-Ceph Cleanup How to Verify Backup Integrity from Ceph Snapshots
How to Create Unique Kubernetes Services per NFS Server i...
Nawaz Dhandala · 2026-03-31 · via OneUptime Blog

How Rook Creates NFS Services

When you deploy a CephNFS resource with multiple active server instances, Rook creates one Kubernetes Service per NFS-Ganesha pod. Each NFS server pod gets its own dedicated Service, rather than a single shared Service load-balancing across all pods. This matters because NFS is stateful - clients must maintain a connection to the same server throughout a session to preserve file locks and state.

Viewing Per-Server Services

After deploying a CephNFS with two active instances, inspect the created Services:

kubectl -n rook-ceph get services -l app=rook-ceph-nfs

You will see one Service per active server:

NAME                         TYPE        CLUSTER-IP      PORT(S)
rook-ceph-nfs-my-nfs-0       ClusterIP   10.96.12.10     2049/TCP
rook-ceph-nfs-my-nfs-1       ClusterIP   10.96.12.11     2049/TCP

Each Service selects exactly one NFS pod by pod name, ensuring sticky routing.

Configuring the CephNFS for Multiple Instances

Set the active count to control how many NFS server pods and Services are created:

apiVersion: ceph.rook.io/v1
kind: CephNFS
metadata:
  name: my-nfs
  namespace: rook-ceph
spec:
  server:
    active: 3

Rook creates pods rook-ceph-nfs-my-nfs-0, rook-ceph-nfs-my-nfs-1, and rook-ceph-nfs-my-nfs-2, each with its own ClusterIP Service.

Exposing Individual NFS Services Externally

To give clients outside Kubernetes access to a specific NFS server, create a LoadBalancer Service targeting one pod:

apiVersion: v1
kind: Service
metadata:
  name: nfs-external-0
  namespace: rook-ceph
spec:
  type: LoadBalancer
  selector:
    app: rook-ceph-nfs
    ceph_nfs: my-nfs
    ceph_daemon_id: "my-nfs-0"
  ports:
    - name: nfs
      port: 2049
      protocol: TCP
    - name: rpcbind
      port: 111
      protocol: TCP

The label ceph_daemon_id: "my-nfs-0" ensures this Service routes only to the first NFS pod.

Distributing Clients Across Servers

Since each NFS server has a unique IP, you can distribute client mounts across servers manually for load balancing:

# Client group A mounts server 0
mount -t nfs4 10.96.12.10:/cephfs-export /mnt/nfs

# Client group B mounts server 1
mount -t nfs4 10.96.12.11:/cephfs-export /mnt/nfs

Clients stay affined to their assigned server as long as the connection is maintained.

Monitoring Per-Server Status

Check the status of each NFS instance:

kubectl -n rook-ceph get pods -l app=rook-ceph-nfs -o wide

For detailed Ganesha status on a specific instance:

kubectl -n rook-ceph exec -it rook-ceph-nfs-my-nfs-0 -- \
  ceph nfs cluster info my-nfs

Summary

Rook creates one Kubernetes Service per NFS server pod, reflecting NFS's stateful nature. Configure the number of servers via spec.server.active in the CephNFS CR. For external access, create additional LoadBalancer Services that select individual pods by daemon ID label. This per-server Service model ensures client sessions remain pinned to a specific server, preserving NFS state and file locking semantics.